Just Call Me Internet

home *** CD-ROM | disk | FTP | other *** search

/ Just Call Me Internet / Just Call Me Internet.iso / archives / com / radio / rli42pet.arc / MBPET.DOC < prev next >

Wrap

Text File | 1987-04-22 | 153KB | 4,027 lines

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * W0RLI MAILBOX WITH PACK-ET-TERM * * * * Version 4.5 ST * * * * PET portions Copyright (c) 1988 C. W. Harrington, WA4GPF * * * * RLI portions Copyright (c) 1986 H. N. Oredson, W0RLI * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * OPERATOR MANUAL FOR THE ATARI ST MAY 15, 1988 PREFACE The author, an unabashed Atari ST enthusiast, developed the original Packeterm program to provide an unsurpassed packet radio terminal program for the ST. Several revisions to correct "bugs" and add features followed. A subsequent undertaking resulted in "porting" to the ST, the widely used MSDOS based W0RLI Packet Bulletin Board Program written by Hank Oredson, W0RLI. The two programs were so complementary, they have now been combined into one integrated program. It turned out to be somewhat more of a challenge than anticipated but nevertheless, has been accomplished. Continual updates to the W0RLI program have been issued and the W0RLI version on which this version of MAILBOX with PACK-ET-TERM is based, is Version 4.5. It is hoped users enjoy this program on their Atari ST computers PACK-ET-TERM COPYRIGHT Copyright (C) 1988 Charles W. Harrington, WA4GPF. Rights to sell are reserved. This program may be freely duplicated and distributed, but not sold without the prior written consent of the author, WA4GPF, Charles W. Harrington, 5634 Lesser Drive, Orlando, Florida, 32818. PACK-ET-TERM DISCLAIMER Charles W. Harrington, the author, makes no warranty as to suitability of this software for any purpose. Further, the author reserves the right to revise this material at any time, without incurring any obligation to former users. The user assumes total responsibility for the use of the software, and agrees not to hold the author responsible for any loss connected with it's use. PACK-ET-TERM SOFTWARE LICENSE The author grants to the public, a limited license to use and reproduce this product, providing the terms of the license and the copyright are complied with. The user agrees that he will not attempt disassembly of this software, and that he will not alter it in any manner, without the prior written consent of the author. This license may be canceled or modified at any time, at the discretion of the author. ACKNOWLEDGEMENTS With the release of this program, I can truthfully say that this has been the result of a TEAM effort. W0RLI and his team, have been working with the MAILBOX source code for a couple years or so, and I have released several earlier versions of the mailbox. Needless to say, without the efforts of Hank and his team, this new program would never have been possible. My thanks to them for writing this fine software and making the source code available to developers like me free of charge. We are all certainly in their debt! I would like to thank the following for their contributions to the program development effort of the W0RLI MAILBOX plus PACK-ET-TERM. Without these people, the development of this program would not have been possible. THANKS TO: W0RLI, Hank N. Oredson and VE3GYQ for developing the packet mailboxes in the C language and sharing their source code with other developers! BETA Testers: Bob Grant, A.R.S WD4BIW Bob Scott, A.R.S. W9BCN (Also edited this DOC file!) Arthur Shipley, A.R.S. N4GPJ Program distribution: Bob McDonald, McDonald Development Group BBS (407) 886-1632 McDonald Computer Center BBS (407) 896-6707 Dave Byrd, A.R.S. KD7VA and the other members of the Atari net for publicizing the availability this software. A special thanks goes out to Phil Bridges, G6DLJ, and of Southampton, ENGLAND. Phil and his AMRAC computer organization have done an outstanding job in distributing my ST software in Europe, and their efforts are greatly appreciated. I would also like to thanks all the users of the W0RLI Mailbox and PET, who have written me the letters of inquiry or reported bugs. I apologize for not getting back and responding to all of you, but program development and work (yes, I have to work for a living to pay for the ST, Hi!) keep me very busy. Be assured that your comments were read, and that your suggestions have gone into this latest release and made it much better than it would have otherwise been. Miscellaneous thanks to: Connie Harrington, my very patient wife and computer widow. THANK YOU ALL VERY MUCH !!! Chuck Harrington, A.R.S WA4GPF 5634 Lesser Drive, Orlando, Florida 32818 TABLE OF CONTENTS CHAPTER 1 - INTRODUCTION Paragraph Page 1.1 Introduction......................................... 1 1.2 Features............................................. 1 1.2.1 W0RLI Mailbox..................................... 1 1.2.2 WA4GPF Pack-et-term............................... 1 1.3 System Requirements.................................. 2 CHAPTER 2 - GETTING STARTED 2.1 Connecting the TNC to the ST......................... 2 2.2 Installation of Program Files........................ 2 2.2.1 Files on the Distribution Disk.................... 2 2.2.2 Installation of Files on Floppy Disks............. 3 2.2.3 STARTGEM.PRG For Autorun of Program............... 4 2.3 Communication Between ST and TNC..................... 4 2.3.1 ST Serial Port RS-232 Parameters.................. 4 2.3.2 TNC Parameters.................................... 5 2.4 Automatic Program Booting After Power Failure........ 6 2.5 Avoiding the "40 Folder" Problem..................... 6 CHAPTER 3 - STARTING THE PROGRAM 3.1 Booting the Program.................................. 6 3.2 Terminal Screen Display.............................. 7 3.2.1 Connect Status.................................... 7 3.2.2 Status of Buffers................................. 7 3.2.3 Status of Printer................................. 7 3.2.4 Screen Colors..................................... 7 3.3 Moving About the Program............................. 7 3.3.1 Mailbox Monitor Mode.............................. 7 3.3.2 Mailbox Sysop Mode................................ 8 3.3.3 Terminal Mode..................................... 8 3.4 Buffers.............................................. 8 3.4.1 Transfer Buffer................................... 8 3.4.2 Receive Buffer.................................... 9 3.4.3 History Buffer.................................... 9 3.4.4 CQ Buffer......................................... 9 3.5 Help Screen.......................................... 9 CHAPTER 4 - PACK-ET-TERM TERMINAL MODE 4.1 Entering Pack-et-term Mode........................... 10 4.2 Unbuffered Keyboard Entry - Transmit Screen.......... 10 4.3 Receive Screen Operation............................. 11 4.4 CONNECT State........................................ 11 4.5 Use of Buffers....................................... 11 4.6 Using the CQ Buffer.................................. 12 4.7 Using the History Buffer............................. 13 4.8 Using the Receive Buffer............................. 13 4.9 Using the Transfer Buffer............................ 13 4.9.1 Use as a Keyboard Buffer.......................... 14 4.9.2 Use for Handling Disk Files....................... 14 4.9.3 Sending Text/BHP Files to the TNC................. 15 4.9.4 Sending Text/BHP Files to the Receive Buffer...... 15 4.10 Additional Commands.................................. 15 4.10.1 <Undo>............................................ 15 4.10.2 <Insert>.......................................... 15 4.10.3 <Alternate><k>.................................... 16 4.10.4 <TA>/<TB>......................................... 16 4.10.5 <C yymmdd hhmm>................................... 16 4.11 Summary of Commands.................................. 16 4.12 Connecting to Another Station........................ 17 4.13 Downloading Text Files From a BBS.................... 17 4.14 Uploading Text Files to a BBS........................ 18 4.15 Blocked Hex Protocol - (BHP)......................... 19 4.15.1 How BHP Works..................................... 19 4.15.2 Uploading a BHP Program to a BBS.................. 20 4.15.3 Uploading a BHP File in Pieces to an RLI BBS...... 21 4.15.4 Downloading a BHP File From a BBS................. 22 4.15.5 BHP/Binary File Conversions....................... 23 CHAPTER 5 - MAILBOX MODE 5.1 About the Mailbox................................... 24 5.2 Entering Mailbox Mode............................... 24 5.3 Customizing Program Files........................... 24 5.3.1 CONFIG.MB........................................ 25 5.3.2 INFO.MB.......................................... 29 5.3.3 FWD.MB........................................... 29 5.4 TNC Configuration................................... 29 5.5 Monitor Mode........................................ 29 5.6 Files For Mailbox Data.............................. 30 5.6.1 MAIL.DAT File....................................... 30 5.6.2 USER.DAT File....................................... 30 5.6.3 LOG.MB File......................................... 31 5.6.4 MON.MB File......................................... 32 5.6.5 CALLS.MB File....................................... 32 5.6.6 BIDFILE.MB File.................................. 32 6.0 PRTLOG.TTP Log File Analyzer........................ 32 APPENDICES Appendix A.....Blocked Hex Protocol Packet Construction...... 33 Appendix B.... Automatic Message Forwarding.....................35 Configuration of FWD.MB File.................. 37 Appendix C.....WP (White Pages) Procedures................... 44 Appendix D.....Mailbox Commands.............................. 46 Appendix E.....Sample CONFIG.MB File......................... 54 CHAPTER 1 - INTRODUCTION 1.1 Introduction Welcome to "W0RLI MAILBOX with Pack-et-term"! This program combines the very popular packet radio W0RLI Mailbox program written by H.D. Oredson, W0RLI, and ported from the MSDOS version to the Atari ST by Chuck Harrington, WA4GPF, with a full featured terminal program, Pack-et-term, written by WA4GPF. Combining the two programs provides packet radio enthusiasts the opportunity to set up their own PBBS on the Atari ST with the ability to quickly change to the terminal mode and enjoy all of the terminal program features provided. A Sysop using this program with an ST will find it very "user friendly". 1.2 Features Some features are common to both the Mailbox and Terminal modes while others are unique to one or the other. Access to most of the features is via keyboard commands and a Help Screen is always available, except during disk access, by hitting the Help Key to show the commands available. 1.2.1 W0RLI Mailbox The full service lan Mailbox has the capability of accepting and storing or, automatically forwarding to other bulletin boards, messages from users via packet radio. Files and programs can be uploaded or downloaded by users even if the Sysop is absent. The Sysop has complete monitoring and editing capability and activities can be logged to an appropriate file for later review if desired. Users can "page" the Sysop and, if he wishes, he can carry on a real-time contact with the user with the full power of the Pack-et-term terminal program available to him. Details of the many features accessible to both the users and Sysop are more fully detailed under Mailbox Commands. 1.2.2 WA4GPF Pack-et-term (Referred to as PET hereafter) In terminal mode, a triple split screen display is provided for operating convenience. Connect status is displayed in the top portion with the receive screen in the center and the transmit screen at the bottom. Several buffers can be toggled off and on to store data with display of each buffer available. Files can be easily uploaded or downloaded. A unique feature is the ability to transfer binary files over packet radio using "Blocked Hex Protocol". With this Users can send and receive ST software by packet radio and BHP files may be generated and stored on the BBS so real time connections are not necessary for transferring binary files. File selector boxes, alert boxes and dialog boxes are utilized to make file handling and feature selection as convenient as possible. W0RLI Mailbox with Pack-et-term Page 2 1.3 System Requirements W0RLI Mailbox with PET requires an Atari 520 or 1040 equipped with at least one floppy disk drive and a B/W or color monitor. The software is written for the MEDIUM or HIGH resolution modes and the use of a TV set with 40 character lines will not be possible. In addition, the program WILL run on the early 520 STs without TOS in ROM, but the size of the RECV and XFER buffers will be quite limited with 512K of RAM. It can also be used with the NEW ROM chips (for use with the blitter) if you have these later chips in your ST. In addition, a TNC will be required. The program was developed with a TAPR type TNC-2 and has been tested successfully with the TNC-1 and PK-232 terminal node controllers. Parameters for each of these TNCs are included on the distribution disk as .set files. CHAPTER 2 - GETTING STARTED 2.1 Connecting the TNC to the ST It is recommended that the RS-232 serial cable for connecting the ST to the TNC be prepared with the following connections although the mass terminated type DB-25 connectors which connect all pins are satisfactory. Pin 1 - Protective ground Pin 2 - Transmitted data Pin 3 - Received data Pin 4 - Request to send (Not presently used) Pin 5 - Clear to send (Not presently used) Pin 7 - Signal ground Pin 8 - Data carrier detect Pin 20 - Data terminal ready (Not presently used) 2.2 Installation of Program Files All of the files required to run W0RLI Mailbox with PET are supplied in the compressed .ARC format on the distribution disk under the filename RLI42PET.ARC and must be de-arced using the ARC.TTP program which is also on the disk. The distribution disk is 227K and the de-arced files total 328K. The de-arced files must then be installed on the program disks. 2.2.1 Files on the Distribution Disk When RLI45PET.ARC is de-arced, the following program files result. CONFIG.MB MBPET.DOC STARTGEM.INF DESKTOP.INF NOTES.PET STARTGEM.PRG ERRORS.TXT PACKET.PRG TEMPLATE.DOC FOLDER.DOC WP.DOC TEMPLATE.PRN FOLDR050.PRG MEDIT.TTP TNC1.SET FWD.MB PRTLOG.TTP TNC2.SET HELP.MB PK232.SET WARNING INFO.MB PRTLOG.TTP WARNING.TWO README.TXT MEDRES.PRG SET1200.PRG W0RLI Mailbox with Pack-et-term Page 3 2.2.2 Installation of Files on Floppy Disks Two formatted floppy disks, one a "boot disk" and the other the "run disk" are required. Copy your accessory file CONTROL.ACC to the root directory of each. Create the folders shown below and install the files in the root directory of one disk. This will be the "RUN" disk. Folders Files AUTO GATEWAY CONFIG.MB PK232.SET FILES MISC DESKTOP.INF PRTLOG.TTP MAIL BBSLIST FOLDER.PRG SET1200.PRG PROGRAMS PACKET FWD.MB STARTGEM.INF MAPS ARRL HELP.MB STARTGEM.PRG BBSFILES INFO.MB TNC1.SET TNC2.SET PACKET.PRG MEDRES.PRG MEDIT.TTP The first time you run PACKET.PRG the following additional files will be automatically created. MAIL.DAT - Mailbox message directory for messages stored in MAIL\. USER.DAT - User file database. LOG.MB - Test file containing the user log. CALLS.MB - List of calls heard. MON.MB - List of calls for the JA and JL commands. BIDFILE.MB - BIDs for bulletins received. The first time the GR or GM commands are used to "untangle" the mail files, the file MAIL.BAK will be created as a backup to MAIL.DAT. The first time the GU command is used to "untangle" the user file, the file USER.BAK is created as backup for USER.DAT. Now copy the following files to the AUTO folder on the RUN disk. Be SURE to copy them IN THE ORDER SHOWN as they will be executed in the order they are copied and the file START.GEM must run LAST. MEDRES.PRG (Not used for monochrome) SET1200.PRG FOLDR050.PRG STARTGEM.PRG The second disk, the BOOT disk should now be configured. Copy DESKTOP.INF and EMULATOR.ACC (from your Atari Master Disk) to the root directory (CONTROL.ACC was copied earlier). Now create an AUTO folder and copy file FOLDR050.PRG into it. You may also put any Desktop Accessory files you may want as well as Clock Drivers, Hard Disk Drivers etc. which you want booted on startup. W0RLI Mailbox with Pack-et-term Page 4 2.2.3 STARTGEM.PRG For Autorun of GEM Program on Bootup Normally, a GEM program cannot be run automatically on bootup by putting it in an AUTO folder. The GEMBOOT program on the disk however, includes STARTGEM.PRG which IS put in the AUTO folder and STARTGEM.INF which goes in the root directory. Listing PACKET.PRG in the STARTGEM.INF file results in the autobooting of PACKET.PRG when AUTO is run. WARNINGS: 1. In installing the files on the disks, DO NOT put any folders within other folders. Doing so may cause the system to "hang up" or trash a floppy disk for you necessitating a re-boot due to a problem in the ST's ROM. Keep all your folders in the root directory. 2. The floppy disk containing the files MAIL.DAT and USER.DAT MUST NOT BE REMOVED FROM THE DISK DRIVE DURING BBS OPERATION.! For instance, with a single drive, you go into PET and then swap disks to load a file into the XFERbuf. When you exit PET, you have a problem!, even if you put the proper disk back in. Apparently TOS detects the swap and will damage the Mailbox files. Hard disk users or those with a second drive can easily avoid this problem. 2.3 Communication Between ST and the TNC In order for the program to operate it is essential the RS-232 serial port of the ST is configured to be compatible with the TNC. It is equally necessary for the operating parameters of the TNC to be set to what is expected by the program. 2.3.1 ST Serial Port RS-232 Parameters Before running the program for the first time, boot up the ST with the boot disk and select the VT-52 Terminal Emulator DESK accessory menu (your disk must have file EMULATOR.ACC from the Atari Master Disk). Turn on the TNC and check for the sign on message which should appear something like this depending on your TNC. (Each line may overwrite on the previous line if automatic linefeed in the TNC is off.): TAPR packet radio ram length is 2000 cmd: If you do not get the sign on message, the serial port of the ST is most likely not configured the same as the TNC. To reconfigure the ST serial port, use Help from the VT-52 terminal mode to get the RS232 PORT CONFIGURATION menu. From this menu the ST's port settings may be altered to establish communication with the TNC. For most TNCs the following settings will work properly. W0RLI Mailbox with Pack-et-term Page 5 Baud Rate: 1200 (choose for comfortable screen viewing) Parity: None Duplex: Half (does not matter) Bits/Char.: 8 Strip Bit: Off Xon/Xoff: On Rts/Cts: Off (The ST does not properly handle ) (hardware flow control. Improper ) (setting will prevent the TNC from) (sending characters to the ST. ) After the settings have been made, save them to your boot disk by selecting "Save DESKTOP" from the Desktop Menu. Your settings will be saved in the DESKTOP.INF file and loaded automatically at boot up. 2.3.2 TNC Parameters TNCs have a number of operating parameters which may be set by the appropriate commands. These commands may vary among different TNCs but the basic parameters are the same. For example, the TAPR TNC2 uses the command "AUtolf" to turn automatic linefeed on and off whereas the PK232 uses "ALFDisp" Some of the parameter settings are irrelevant so far as this program is concerned. For your convenience, files TNC1.set, TNC2.set and PK232.set have been furnished which contain the critical commands for each TNC. After the program is up and running, these commands can be given to the TNC by downloading the file from the Sysop prompt in the Mailbox mode using the command DA PK232.set. (See Para. 5.3) Some of the commands are critical to correct operation so be sure the correct commands are used for your TNC. As an example, the commands in PK232.set for use with the PK232 TNC are shown below. 8BITCONV ON FLOW ON PACLEN 128 ALFPACK OFF HBAUD 1200 PARITY 0 AWLEN 8 HEADERLN OFF ACRDISP 0 BKONDEL ON CASEDISP 0 REDISPLAY 0 CANLINE 0 LCOK ON RELINK OFF CANPAC 0 ALFDISP OFF SENDPAC $0D CBELL OFF MCON 0 START $11 CHECK 0 MDIGI OFF CHSWITCH 0 COMMAND $03 MONITOR OFF STOP $13 CONOK OFF MRPT OFF TIME 0 CONMODE CONVERSE NEWMODE OFF TRACE OFF CWID 0 NOMODE OFF TRFLOW OFF ACRPACK ON NUCR OFF TXFLOW OFF DELETE OFF NULF OFF VHF ON ECHO OFF NULLS 0 WIDE OFF XFLOW ON XON $11 XOFF $13 W0RLI Mailbox with Pack-et-term Page 6 2.4 Automatic Program Booting After Power Failure In unattended operation of the Mailbox it is desirable to provide for automatic return to on-line status after a momentary power interruption. By using two disks, the boot disk and the run disk, the system will recover when the power returns. In normal start up, the boot disk is used first. This sets up the screen colors and other parameters (DESKTOP.INF file) and stops with the disk directory being displayed. Substituting the run disk and clicking on PACKET.PRG starts the program. After a power failure, with the run disk still in the disk drive, the computer reboots but this time the files in the AUTO folder are run first which sets the parameters and automatically runs the Mailbox program. The screen colors in the DESKTOP.INF file on the run disk are different from those chosen for the boot disk so that BLUE/WHITE screen gives visual evidence that a power interruption has occurred and a reboot has taken place. It is recommended that when it is noticed that a power interruption has occurred, a manual reboot be done, going back to the boot disk and again substituting the run disk for normal operation. The reason for the manual reboot is to reactivate DOS error checking which is bypassed when an automatic reboot takes place. 2.5 Avoiding the "40 Folder" Problem Unfortunately, the ST ROM has a "bug" which plays havoc with your files or causes the system to "hang up" and necessitate a reboot if you exceed approximately 40 folders on any disk. If folders are nested within other folders, each access is interpreted by the ST as another folder and the limit can be easily reached. The program FOLDR050.PRG in the AUTO folder of both the boot and run disks adds an additional 50 folders to the limit and should prevent the problem but additional testing is needed to determine if this prevents the problem in all circumstances. It is best to play safe and not exceed 90 folders and DO NOT NEST FOLDERS WITHIN FOLDERS!! CHAPTER 3 - STARTING THE PROGRAM 3.1 Booting the Program After communication between the ST and TNC has been established, run the program and get accustomed to its features. Shut off the ST, insert the boot disk and power back up. The Desktop should appear with the A: directory displayed. Substitute the run disk for the boot disk, hit <Esc> to display the run disk directory and click on PACKET.PRG. If all is well, the Mailbox should come up running in the monitor mode ready to accept users. In the monitor mode you will be able to see packet traffic on the screen. If the program fails to run, check to be sure CONFIG.MB has been customized properly as per Appendix B as an improper CONFIG.MB file will prevent the program from operating. Also check the RS232 parameters and TNC parameters to make sure they have been set properly. W0RLI Mailbox with Pack-et-term Page 7 3.2 Terminal Screen Display You will notice the screen is split with the top showing the connect status and current time (actually the time of the last screen scroll). Just below is the status bar showing the status of RECVprn, CONNprn,XFERbuf and RECVbuf. The text screen is below the status bar. 3.2.1 Connect Status The connect status in the upper left corner of the screen probably shows "*** Disconnected". If a user connects this will change to "*** Connected to W4XXX" If digipeaters are in the connect path they will be indicated. 3.2.2 Status of Buffers The various buffers are opened, displayed and closed by the function keys. The current status of each buffer is shown on the buffer status line and the video reverses as the buffers are opened and closed. 3.2.3 Status of Printer The printer can be toggled on and off to print all packets received OR just those packets received while you are connected. The status line shows CONNprn and RECVprn to indicate which, if any, are in the ON state. 3.2.4 Screen Colors The screen colors are set by the DESKTOP.INF file. They may be changed if you desire by bringing up the Control Panel (if CONTROL.ACC is on the disk), adjusting the colors on the color palette and then saving by clicking on Save Desktop 3.3 Moving About the Program Moving from mode to mode, toggling or displaying buffers, etc. is easily accomplished by either simple commands from the keyboard or by the function keys. A convenient "help screen" with all the commands is readily available by hitting the Help key (except during disk access). A convenient template for placing over the function keys to remind you of their uses is available by printing the file TEMPLATE.PRN on the distribution disk from the Desktop. 3.3.1 Mailbox Monitor Mode When the program is run, it comes up in the monitor, or "on-line" mode ready for any user to access. Commands have been automatically given to the TNC to turn the monitor on and allow connects with the "conok" command. To go to the "Sysop mode" which allows the Sysop to access the Mailbox for monitoring the Mailbox or performing housekeeping chores, use <CTRL> E or the <Undo> key. You will see "1230, 3 msgs>" which is known as the Sysop prompt indicating the Sysop now has access to the Mailbox (1230 is current time). Return to monitor mode is accomplished by the command ye <Return>. W0RLI Mailbox with Pack-et-term Page 8 3.3.2 Mailbox Sysop Mode In the Sysop mode, the Sysop has a large variety of local commands available. Complete details are included under the operational portions of this manual. While in this mode the Sysop can perform many functions, including a few of the major ones listed below. (1) Connect to a user. (2) Download a file such as TNC2.SET to the TNC to set parameters for Mailbox operation. (3) List all users of the Mailbox. (4) List messages in the Mailbox. (5) Edit messages. (6) Kill messages. (7) Place messages in the Mailbox. (8) Upload files of interest to users to the Mailbox. (9) Go from Mailbox mode to PET "terminal" mode. 3.3.3 Terminal Mode When the you want to go to the terminal mode for normal packet communications in real time, the command "< TA ><Return> " from the Sysop prompt will put you in the terminal mode. You are now in PET with its many convenient features. You will immediately see the screen display has changed into a triple split-screen presentation with a command bar near the bottom separating the receive text and the transmitted text from the keyboard. This new lower status bar shows the status of the Auto CQ feature, display (off/on) of the transfer, receive and history buffers,sending of the transfer buffer and downloading to the transfer buffer. In the center of the command bar is a blank area where messages from the program to you will be displayed.The use of the options will be discussed in detail in the operational section for the terminal mode in this manual. 3.4 Buffers There are four buffers available, transfer, receive, history and CQ. All except the history buffer can be toggled off and on, loaded, displayed or sent by the appropriate use of the function keys. The history buffer is always on and can only have the display toggled off and on, or be saved to disk. The Help screen will provide information on which keys to use for the various functions. While displaying the contents of the buffers, you may scroll through the text a page at a time by hitting any key. The < + > key ON THE KEYPAD will jump ahead approximately 2K in the buffer and the < - > key will move backward approximately 2K. Using the < * > key ON THE KEYPAD will move to the end of the buffer. Detailed functions will be covered later in this manual. Buffer sizes are determined by available RAM and are displayed at the bottom of the Help screen. The number of bytes in the buffer being displayed will be shown by first toggling the display off, followed by < Alt >< r >, < Alt >< h > or < Alt >< x > for the receive, history or transfer buffers. 3.4.1 Transfer Buffer The transfer buffer may be used as a keyboard buffer or be loaded with a file from disk using <F4>. Its contents may be displayed <F6>, cleared <F3>, sent to either the TNC or the receive buffer<F8> or saved to disk <F5>. W0RLI Mailbox with Pack-et-term Page 9 3.4.2 Receive Buffer The receive buffer receives all incoming characters from the TNC or data directed to it from the transfer buffer, if toggled to the on status using <Shift><F7>. This buffer too may be displayed <Shift><F6>, cleared <Shift><F3> or saved <Shift><F5>. 3.4.3 History Buffer This buffer records user activity on the BBS. It is actually a round buffer,as, when the end is reached, the pointer wraps back to the beginning. It is always active and cannot be turned off. Display of the history buffer is toggled on and off by using <F10> and it may be saved to disk with <Shift><F10>. 3.4.4 CQ Buffer This buffer can be loaded with a CQ file <F1> which has been previously entered into the transfer buffer from the keyboard and saved to disk. It may be displayed <Shift><F1>, transmitted <Shift><F2> or, can be automatically sent periodically if Auto-CQ has been toggled on <F2>. 3.5 Help Screen Hitting the <Help> key will bring up a color coded Help screen. Assuming the default PET colors of black screen and white, red and green text, the color codes have the following meaning. Green - These commands apply only while in PET. White - These commands apply in all modes. Red - These commands apply in Mailbox Sysop mode only. Monochrome users will be unable to use this color coding so the following reference is provided. PET Only Mailbox Sysop Mode <F1> and <Shift><F1> [C yymmdd] - Set system time. <F2> and <Shift><F2> [TA] or [TB] - Enter PET mode. <F3> and <Shift><F3> <F4> and <Shift><F4> <F5> and <Shift><F5> <F6> and <Shift><F6> <F7> <F8> and <Shift><F8> <F10> and <Shift><F10> All other commands on the help screen are available in ALL modes. At the bottom of the screen, the memory available for each buffer is shown. To exit the help screen, TOUCH ANY KEY. Normal program operation continues while the help screen is displayed. You will not be able to toggle it off and on when the disk drive is running however. There is also a help file which the Sysop or users may access with the " H " command while in the Mailbox mode. W0RLI Mailbox with Pack-et-term Page 10 CHAPTER 4 - PET TERMINAL MODE 4.1 Entering PET Mode When W0RLI with PET is booted, the program comes up in the monitor, or on-line mode of the Mailbox, ready for users to connect. To move to the PET terminal mode, you must first go to the Sysop mode using <CTRL><E> or <Undo> . When the Sysop prompt appears (time, 5 msgs>), use the command "<TA><Return>" to go to terminal mode. If, while in the Mailbox monitor mode and a user is connected and is sending the command " T " which pages the Sysop with a ringing bell, pressing ANY key will put you immediately in terminal mode ready to send a message to the user. In terminal mode a command bar appears dividing the received text in the center of the screen from the keyboard characters at the bottom. This status bar displays the current status of the following functions: Function Control Keys AUTOcq0 (automatic CQ toggle) <F2> XFERdisp (display transfer buffer) <F6> RECVdisp (display receive buffer) <Shift><F6> HISTdisp (display history buffer) <F10> XFERdnl (download to transfer buffer) <Shift><F8> XFERsend (send transfer buffer) <F8> 4.2 Unbuffered Keyboard Entry - Transmit Screen The cursor, which is an underline character, is located in the transmit screen area. When the transfer buffer is closed, ascii characters are sent to the tnc one at a time as they are typed from the keyboard. Holding a key down, will result in an automatic repeat of the character. Also, the "key click" will be heard, assuming that it has not been turned off at the control panel, or that the volume is not turned down low. Typing errors are corrected by the <Backspace> key, assuming a carriage return has not been hit yet. Once the return key is hit, no changes are possible in the preceding text, and the tnc will act upon what you have entered. If characters entered from the keyboard appear on the receive screen as they are typed, the ECHO parameter in the tnc is turned on. Echo to the receive screen is not desirable during split screen operation! <CLR/HOME> will clear the transmit screen and send the cursor home, while sending a Control-x to the TNC will cancel any characters typed since the last <Return>. W0RLI Mailbox with Pack-et-term Page 11 4.3 Receive Screen Operation All ascii characters sent by your TNC to the ST over the RS-232 interface, will be displayed in the center (receive) portion of the screen. You may pause the printing of new characters to the receive screen by, using <CTRL><s>. Printing is restarted using <CTRL><q>. You may pause the printing of new characters to the receive screen during unbuffered keyboard entry by setting the FLOW parameter in your TNC to ON. It should also be noted that the speed at which text is printed to the receive screen may be altered for operator comfort by adjusting the RS-232 baud rate in the ST and TNC. PACK-ET-TERM will function at 9600 baud, but some people may not be able to read the text before it scrolls off the screen! Also, if AUtolf is not set to OFF in the TNC, lines will print double spaced on the receive screen. 4.4 Connect State The CONNECT STATE display feature is one of the unique features of PACK-ET-TERM. When you become connected to a station, the connect message, along with the time will be printed in the upper left hand corner of the screen. In addition, the ST's bell will also ring to alert you to the fact that a connection has just been made. A typical connect message on a TNC-1 would be: *** Connected to WA4GPF at 18:04 On the TNC-2 types, the path will also be displayed: *** Connected to WA4GPF via ORL at 18:04 Either *** Connected, *** Linked, or *** Disconnected messages will be printed to the "Connect state" area of the screen, all the way to the messages line feed! The program reduces the chance of false connects which are sometimes generated by other stations transmitting *** CONNECTED messages in their text. PACK-ET-TERM will not validate *** CONNECTED messages unless printed at the beginning of the line, or the left side of your receive screen. 4.5 Use of Buffers In Paragraph 3.4 the various buffers available in PET were discussed briefly along with the function keys to open, close and display them. The proper use of these buffers, particularly the transfer buffer, warrants some further discussion here as they are an integral part of the unique file handling capabilities available. The buffers are opened, displayed, cleared, saved or sent by using the appropriate function keys. See the Help screen for the specific keys for each buffer function. GEM File Selector Boxes and Alert Boxes are widely used to display directories for selection of the desired filenames for transferring to and from buffers. File Selector Boxes are also used to select the desired file to "Kill" with the KILL command (ALT-K). In some cases, Alert Boxes are used to verify the action which has been requested. W0RLI Mailbox with Pack-et-term Page 12 4.6 Using the CQ Buffer It is convenient to be able to store a "canned" CQ message on disk and be able to call it up at will when calling CQ. The CQ buffer is a small buffer to which the CQ message can be loaded, and then sent to the TNC. The CQ buffer may be loaded from disk only. CQ messages are typed into the transfer buffer and then saved to disk. Hitting the <F1> key will bring up a File Selector Box from which you can select the CQ message file you want to load. You may abort from entering a filename by hitting the <Esc> key. Please note that the CQ buffer will not hold messages longer than 256 bytes! Very long CQ messages sent automatically would cause unnecessary QRM! Should you attempt to load a longer file into the CQ buffer, you will receive a " File > CQ buffer " message. If the file is successfully loaded, you will receive " n bytes in CQ buffer " message. The contents of the CQ buffer may be displayed by hitting the <Shift><F1> key sequence. If the buffer is empty, you will see a " CQ Buffer Empty " message. AUTO CQ may be turned on by hitting function key <F2>. You will be prompted on the receive screen with the question: 1 to 9 minutes? You must enter a number between 1 and 9 minutes. If you enter <5>, AUTOcq5 will be printed on the command line in red. AUTOcq is now turned on. Every five minutes, the contents of the CQ buffer will be sent to the TNC, assuming no characters have been printed to the receive screen in 5 minutes! For example, lets say I have loaded my CQ message into the CQ buffer, and it is: CQ: This is Chuck in Orlando....k PET will send this message to the TNC every five minutes, provided that no characters are received at the RS-232 port! AUTOcq is sent after 5 minutes of no activity on the packet channel. Your TNC must be in converse mode, and your CQ will be sent as set in your UNPROTO parameter in the TNC. So, after every five minutes that elapses without channel activity, the following message would be sent: WA4GPF>CQ: CQ This is Chuck in Orlando....k Hitting the <F2> key again will reverse the AUTOcq to normal black letters, and disable the AUTOcq feature. The contents of the CQ buffer will be sent to the TNC without delay, when the <Shift><F2> key sequence is hit. If the CQ buffer is empty, a " CQ buffer empty " message will appear. W0RLI Mailbox with Pack-et-term Page 13 4.7 Using the History Buffer The HISTbuff is merely a "circular" buffer that records user activity on the BBS. The amount of data saved depends on the memory automatically allocated to the buffer and when its limit is reached, the earliest data is overwritten by the latest data. The Sysop can learn a great deal about the nature of the activity on his BBS by referring to the HISTbuff. It is always active and may NOT be turned off. Display of the information in the HISTbuff is toggled on/off with function key <F10> and it may be saved to disk using <Shift><F10>. The number of bytes stored in the buffer is displayed with the command <Alternate><h> (provided the buffer display has previously been toggled off). As with all the buffers, scrolling through the buffer can be accomplished a page at a time with ANY key, 2K with each <+> FROM THE KEYPAD, 2k backward using <-> or, go directly to the end of the buffer with <*>, again from the keypad. 4.8 Using the Receive Buffer The RECVbuff may be toggled on/off with the key sequence <Shift><F7> and displayed with <Shift><F6> after closing the buffer. The RECVbuff cannot be toggled with the display on. Scrolling through the buffer is accomplished in the same manner as all the other buffers. Unlike the display of the transmit buffer, the display of RECVbuff does not generate a linefeed and expects to have each line in the buffer terminated with a line feed for proper display. This buffer records everything that goes to the screen. Data from the transfer buffer or disk drive may be directed to it. The capacity of the RECVbuff is displayed at the bottom of the Help Screen and the number of bytes in the buffer may be displayed with the command <Alternate><r> (providing the buffer display has been previously toggled off). This buffer may be saved to disk with <Shift><F5> or cleared with <Shift><F3>. Files may be loaded into the RECVbuff from either the disk drive using <Shift><F4> or, may be loaded from the transfer buffer using <Shift><F8>. Loading from the transfer buffer is part of the process of converting text to binary files and vice-versa and will be discussed in more detail under the transfer buffer procedures. 4.9 Using the Transfer Buffer The XFERbuff is similar to the other buffers in some ways. It can be toggled on/off with <F7>, displayed with <F6>, cleared with <F3>, loaded with <F4> and saved with <F5>. A number of unique functions may be implemented with the XFERbuff and these warrant a more detailed explanation. Scrolling is accomplished in the normal way, using any key, <+>, <-> and <*>. W0RLI Mailbox with Pack-et-term Page 14 4.9.1 Use as a Keyboard Buffer The XFERbuff can be opened with <F7> and accept characters from the keyboard to produce a text file. Typing errors can be corrected with the Backspace key, up to the next carriage return. Once the return key has been hit, no changes in the preceding text may be made. When the text file has been completed, the buffer is closed with <F7>. It can then be displayed with <F6>, cleared with <F3> or saved to disk with <F5> after which you will be prompted for a filename with a File Selector Box. You may edit the File Selector Box to show the directory, including the drive, to which you want to save the file and type in the filename. If you change the drive, click INSIDE THE BOX after editing the drive and a new box will appear with the desired drive path shown. An example might be A:\*.* if you wanted to save the file to drive A: under the filename you typed on the filename line. The file in XFERbuff, whether typed there from the keyboard or loaded from disk with <F4>, can be sent to the TNC using <F8> by choosing the Text option from the Alert Box which the <F8> command produces. A second Alert Box appears offering a choice of TNC or RECVbuff. Choosing TNC sends a previously typed message file through the TNC to the station you are connected to. Another convenient use for the XFERbuff is for typing TNC parameters desired for the W0RLI with PET program into the buffer, saving them to disk, and then recalling them when wanted and sending them from the XFERbuff to the TNC, in COMMAND mode, to configure it in the proper way for the program. The TNC wants to see the commands from the buffer WITHOUT line feeds. An option is presented to Strip Line Feeds in an Alert Box after Text and TNC choices have previously been made. 4.9.2 Handling Disk Files You may load a file from disk into the XFERbuff with the <F4> key. A File Selector Box will appear with the directory of the drive which was active when the program was loaded. If the file desired is on another drive, use the arrow keys to move the cursor and edit the header in the File Selector Box to indicate the proper drive and file path and CLICK INSIDE THE FILE SELECTOR BOX. A new directory will appear showing the files on the drive path you entered. You can then select the file you wish to load to the XFERbuff. If the file is too large for the available buffer size, an error message will appear. If the file is loaded, "n bytes in XFERbuf" will be printed. Once a file is loaded into the XFERbuff, hitting the Send XFERbuff key <F8>, produces an Alert Box providing the option of TEXT or BHP. Either choice will produce another Alert Box to choose TNC or RECVbuff. Still another Alert Box allows you to Strip Line Feeds if you want. The contents of the XFERbuff will then be transferred to either the TNC or RECVbuff in either TEXT or BHP modes, depending on the choices you have selected.. For now, just consider BHP a binary file as opposed to a text file. The BHP protocol for transferring of binary files is a very unique part of PET and is covered in detail under the section BHP Protocol. W0RLI Mailbox with Pack-et-term Page 15 4.9.3 Sending TEXT/BHP Files to the TNC If the TEXT mode was selected with the TNC as the destination, the buffer is sent to the TNC. If the TNC is in the COMMAND mode, the data sent is interpreted as a command to the TNC. This can be in the form of proper commands to change TNC parameters if it is desired to set up the proper TNC parameters. Strip the line feeds before sending the commands to the TNC. If the TNC is connected to another station, the data is sent out over the air to the connected station. This would be the obvious approach to upload a file to a connected station, however, the subject of file transfers will be dealt with in another section since this is another topic in itself. If BHP mode was selected with the TNC as the destination and the TNC was connected to another station, the file would be sent out over the air. A BHP file is a representation of a binary file and is the way binary files can readily be uploaded to other stations using PET. The significance of the BHP protocol is such that an entire section of this manual will be utilized to deal with this subject. 4.9.4 Sending TEXT/BHP Files to the Receive Buffer Depending on whether TEXT or BHP was selected and the files sent to the RECVbuff, the file will be located in the RECVbuff either as an ASCII text file or a .BHP file. Again, .BHP files are discussed in detail elsewhere in this manual. For now, it is sufficient to say that binary files are ALWAYS located in the XFERbuff and the .BHP version of those files are in the RECVbuff when transferring binary files between the two buffers. The .BHP file in the RECVbuff can be saved to disk as a .BHP file, uploaded to other packet operators or BBSs or, placed on your own BBS available for those users who wish to download the program and convert it back to a binary file, ready to run on their ST. (See also Paragraph 4.15.5). 4.10 Some Additional Commands In addition to the commands discussed previously, there are some other convenient commands. (See Help Screen). 4.10.1 <Undo> This command switches to the BBS Sysop mode from either the PET or Mailbox monitor mode. It will also break in on a user if the Sysop desires to converse with him. Leave the TNC in COMMAND mode (cmd: prompt) before using the <Undo> key to exit unless, you entered PET mode in response to a " T " command from a user. In this case, use <Control><E> to leave the TNC in CONVERSE mode so the user will retain the connection to the Mailbox and he can disconnect when he wishes. 4.10.2 <Insert> This command is used to kick a user off the BBS (Not nice!) if he attempts to use an illegal call or some other unacceptable behavior. <Control><F> will perform the same function. W0RLI Mailbox with Pack-et-term Page 16 4.10.3 <Alternate><k> (PET mode only) This command can be used to kill a disk file. The command brings up a File Selector Box for selection of the file to be killed. You may edit the file path information of the File Selector to bring up the directory which includes the target file. 4.10.4 <TA> or <TB><Return> (BBS Mailbox Only) This command, given at the Sysop prompt in Mailbox mode switches to PET mode and connects either Port A or Port B of the ST. Unfortunately, the ST does not have a second RS-232 Port B for dual port operation so Port B has been routed to the MIDI port. It is feasible (maybe not practical), to use another ST and connect the STs MIDI ports together. A simple program (not written) could be used to connect the second ST's MIDI and RS-232 ports and some alteration of the CONFIG.MB file would enable dual port operation. So far as is known, this has not actually been tried. It is hoped that some sort of second RS-232 port may become available for the ST which would make dual port operation simple and convenient. 4.10.5 <C yymmdd hhmm><Return> This command is used to set the internal clock so that all features which incorporate a display of real time will be correct. If the clock was correct when the program was run, there is no need to use this command. 4.11 Summary of Commands For convenience, all of the commands available are listed below. These commands are also shown on the Help Screen. <F1> - Load CQ Buffer <Shift><F1> - Display CQ Buffer <F2> - Toggle Auto CQ <Shift><F2> - Send CQ Buffer <F3> - Clear XFERbuff <Shift><F3> - Clear RECVbuff <F4> - Load XFERbuff <Shift><F4> - Load RECVbuff <F5> - Save XFERbuff <Shift><F5> - Save RECVbuff <F6> - Display XFERbuff <Shift><F6> - Display RECVbuff <F7> - Toggle XFERbuff <Shift><F7> - Toggle RECVbuff <F8> - Send XFERbuff <Shift><F8> - BHP Download <F9> - Toggle RECVprn <Shift><F9> - Toggle CONNprn (F10)- Display HISTbuff <Shift><F10>- Save HISTbuff <Help> Help Screen <Alt><h> - Bytes in HISTbuff <Undo> Switch to Mailbox Mode <Alt><k> - Kill Disk File <Insert>Kick User Off <Alt><r> - Bytes in RECVbuff [C yymmdd hhmm] -Set System Time <Alt><x> - Bytes in XFERbuff [<TA> or <TB><Return> from console to enter PET mode for Port A/B W0RLI Mailbox with Pack-et-term Page 17 4.12 Connecting to Another Station When in the PET mode you can connect with another station using standard packet techniques. From the cmd: prompt, C W9BCN will initiate a connect in the normal fashion. It should be noted that when using <TA><Return> to enter PET from the BBS Sysop prompt, the TNC will have both MONITOR OFF and CONOK OFF so you will see no packets being sent and no other station can connect with you. You can change these if you wish. By using the various commands already discussed, you can print incoming packets, record them in the RECVbuff and save them to disk if you wish. Files can be downloaded from BBSs and uploaded from the XFERbuff. 4.13 Downloading Text From a BBS Incoming text must be saed to the Receive buffer. Assume we are connected to a BBS that has a file named TNC.DOC that we wish to download and save to disk. Here is the procedure, a step at a time. (1) Clear the contents of the receive buffer wilth <Shift><F3>. You shold get a "RECVbuff Cleared!" message. Make sure the monitor is set to OFF with the monitor command for your TNC (normally M or MC). (2) Type in the command that starts the BBS sending the file but do not hit <Return> yet! In the case of a W0RLI BBS it would be " D TNC.DOC ". (3) Use <Shift><F7> to open the Receive buffer. RECVbuff should now be highlighted indicating it is open. (4) Now that the RECVbuff is open to receive the file, trigger the download command to the BBS typed in Step (2) above by hitting the <Return> key. The BBS responds by sending file TNC.DOC and you will see it coming across your Receive Screen. (5) After the file has been received from the BBS, use <Shift><F7> to close the Receive buffer. RECVbuff on the status line will no longer be highlighted on the status bar. (6) To find out how many bytes are in the Receive buffer, use <Alternate><r>. (7) To save the Receive buffer to disk, use <Shift><F5>. A File Selector Box will appear for you to enter the filename you wish to use for the downloaded file. In this case TNC.DOC would be appropriate. You can edit the File Selector Box to change the drive and file path if you wish. Click inside the box to change the Directory. The file will be saved to the disk you have specified. The number of bytes saved will be displayed. If the number is less than the number of bytes in the buffer displayed in Step (6), there was not enough room on your disk to save the entire file and you should insert another disk and resave the file. (8) Print the downloaded file on the receive screen with <Shift><F6>. Use <+>, <->, <*> (from the keypad), and <Space Bar> to page through the file. Exit back to the terminal mode by touching the <ESC> key. W0RLI Mailbox with Pack-et-term Page 18 4.14 Uploading a Text File to a BBS You may send a file to a BBS with this procedure. The file must be in the transfer buffer (XFERbuff) for an upload. The file cannot exceed the maximum buffer size, which is dependent on the RAM available at program entry. The following procedure loads the file into the XFERbuff and sends it to a BBS: (1) The XFERbuf must be closed! If it is highlighted on the status bar, it is open and must be closed with <F7>. (2) Touch the <F4> key. You will now be prompted with a File Selector Box for selection of the file you wish to upload. If it is not on the drive shown in the Box, edit the information to show the proper path for the file you want. Clicking INSIDE THE BOX will bring up another directory and you can select the file by clilcking on it. When the file has been loaded, the number of bytes in the XFERbuff will be displayed. (3) You may use the <F6> key to see the file now in the XFERbuff. If it is a long file and you do not care to page through the whole thing, you may use the <ESC> key to exit. (4) Send whatever the BBS needs to upload a file, usually " U TNC.DOC ". You will be told to send your file and terminate it with some end of file character. On the W0RLI BBS this character is <Control><z> and is followed by a <Return>. (5) Use the <F8> key to send your file. Be sure you are in CONVERSE mode! Choose Text from the Alert Box which appears with the options Text and BHP. Choose TNC from the next Alert Box. A third Alert Box will appear asking whether or not line feeds should be stripped. Answer NO. A counter at the center of the command line will count the characters as they are transferred to your TNC. If your packet channel is very busy, you may wish to pause the transfer of characters to your TNC. Do this by hitting the <Space Bar>. When you want to resume transfer, you may do so with the <Space Bar> a second time. Should your TNC's buffer get way behind, it will send a <Control><s> to PET and you will get a message " Xoff Rcvd: Tnc Full! ". You should not touch any keys. The transfer will continue as soon as the TNC's buffer empties. Hitting the <ESC> key any time during a file transfer will cause an abort. When all of the XFERbuff has been sent to the TNC by PET, you will see " Txt File Sent! " . (6) Send the end of file character to let the BBS know that all of the file has been sent. <Control><z> is the EOF file character for a W0RLI BBS, followed by a <Return>. /EX is also supported as an EOF character because many European computers cannot generate <Control><z> and use /EX instead. W0RLI Mailbox with Pack-et-term Page 19 4.15 Blocked Hex Protocol (BHP). - What is it? Blocked Hex Protocol, or BHP for short,is a new way to transfer binary files via packet radio using 8bit data bytes. Text files are sent with 7 bit data bytes. BHP files are sent in the TNC's converse mode, which maintains compatibility with the existing W0RLI BBS system. In fact, during BETA testing of this program, PET actually forwarded itself via several RLI mailboxes in as many as a dozen separate messages! This method was used by the author to get program upgrades to his BETA testers. The ability of BHP to break a large program into smaller sections, and transfer them through Mailboxes, should be a big break through for packet radio. The author reminds all PET users that only Public Domain and "Freeware" type software should be transferred over packet radio. It is, of course, OK to send PET! 4.15.1 How BHP Works. Blocked Hex Protocol takes a binary file and breaks it into "blocks", each BHP block having 50 binary bytes. Similar to Hex, BHP blocks are ASCII representations of the binary code, which allows transmission over packet in the converse mode. When sending a BHP file over packet, the first BHP packet sent is the "Header" packet. The Header contains the file name, the total length of the file being transferred, the load address (not used on the ST), the execution address (not used on the ST) and a checksum. In the ST, this header will open the transfer buffer to the total size of the file being transferred and not just a size for the current transfer section! If the program is being transferred is 5K bytes in size, that is the size the transfer buffer is set to, even though you may actually send it in five 1K pieces. After the header, one or more data blocks will follow, each block representing up to 50 binary bytes. The blocks, which are numbered 0 to n, may be collected by the downloading station in any order. The block number is a buffer offset address and the incoming block is stored at (block number x 50) address in the transfer buffer after the validity of its checksum has been verified. See Appendix A for details of the BHP packet construction. Should a checksum error appear while receiving a header, the transfer must be aborted! A checksum error while receiving a data block is not fatal, but the user is reminded to note the the number of the bad block, so that the missing block may be repeated later. The order in which blocks are received is of no importance, for PET will use the block number to place the data where it belongs in the transfer buffer. To understand how this works, think of the transfer buffer as bookshelf. The sending station has a book shelf just the size to hold all of the books (blocks) and tells the receiving station what size book shelf to build (by sending the XFERbuf size in the first header packet). The sending station then begins to send the books (data blocks). Each book is numbered so it slides into the proper position in the book shelf as it is received. It does not matter in what order the books are received. When all of the books are present in the receivers bookshelf, the shelf is full, and his collection is complete. The contents of the XFERbuf (bookshelf), can then be saved to disk and run! W0RLI Mailbox with Pack-et-term Page 20 4.15.2 Using BHP to Send a Program File to a BBS. The following example will upload a short program called MEMTEST.PRG to a W0RLI type BBS using the BHP format. This example will illustrate the transfer of a BHP file that is small enough to be sent in one transfer session. (1) Assume you have already connected with the BBS and it is patiently awaiting your next move. (2) Touch the <F4> key to load the file into the transfer buffer. Enter the name of the file you wish to send, MEMTEST.PRG. If the file is loaded, the number of bytes loaded will be printed on the receive screen. (3) Enter from your keyboard and send to the BBS: U MEMTEST.PRG (4) The BBS will tell you to send the file and end with a <Control><Z>. To send the BHP file, touch the <F8> key and choose BHP at the "Text or BHP" option in the Alert Box. Another Alert Box will allow you to choose the TNC as the destination for the file. You will be asked for the filename. Answer MEMTEST.PRG. Now you will be asked for the beginning block number. Answer by just hitting <Return> which gives the default entry of zero for "start at the the beginning of the file". Now you will be asked for the ending block number. Hit <Return> which gives you the default for the last block of the file, whatever it is. You will now see "Sending Block# n" at the center of the command line. You may check the progress of the transfer by watching the TNC's "STATUS" light, which indicates that data is in the TNC's buffer that has not been sent yet. To pause the transfer of blocks from PET to the TNC, you may do so with the <Space Bar>. When the status lamp goes out, you may resume the transfer by touching the <Space Bar> a second time. If the TNC's buffer should become full during the transfer, the message "Xoff RCVD:TNC FULL! " will be printed on the command line. You need take no action. As soon as the TNC sends some of the packets, it will signal to PET with a Control-Q and the transfer will resume. When you see the message, "BHP File Sent!", type a <Control><Z> followed by <Return> from the keyboard to signal end of file to the RLI type BBS. W0RLI Mailbox with Pack-et-term Page 21 4.15.3 Uploading a BHP File in Pieces to a RLI BBS. Files that are longer than about fifty blocks (2.5K) may be sent in sections more conveniently. This is one of the best features of BHP. Keep in mind that each block is fifty binary bytes. Suppose you wish to send a file named LONGFILE.PRG that is 8K in length. We will break the file into three pieces for about fifty blocks in each portion. Assume we are connected to the BBS and are going to send the file "LONGFILE.PRG" to station WZ4FCC. The command to use is: S WZ4FCC @ DEST The BBS requests a title for the message. We enter: LONGFILE.PRG BHP 0-50 The format for the filename is optional. We have indicated this is a BHP program file which contains blocks 0 thru 50. The BBS prompts for the message to be sent. Use the <F8> key as before and choose BHP when the Text/BHP option in the Alert Box appears. Enter <Return> at the beginning block prompt and enter 50 for the ending block prompt. When the prompt "Hex File Sent" is seen, send the <Control><Z> to the BBS to close the message. Remember that a <Return> for a beginning block prompt will start at the beginning of the file. It enters a default zero for you. For the second section, repeat the above procedure except use the message title "LONGFILE.PRG" BHP 51-100 and enter 51 for the beginning block # and 100 for the ending block #. On the third section, use the title "LONGFILE.PRG" BHP 101-EOF and enter 101 for the beginning block number and <Return> for the ending block prompt. Remember that a <Return> for the ending prompt will take you to the end of the file. You may break BHP files into as many sections as you wish using the above method. W0RLI Mailbox with Pack-et-term Page 22 4.15.4 Downloading a BHP File From a BBS. The following example will illustrate the procedure for downloading a BHP file called MEMTEST.BHP from a W0RLI BBS. Assume a connection exists with the BBS. BHP downloads always go to the XFERbuff. (1) Clear the XFERbuff with <F3>. An Alert Box for confirmation that you DO want to clear the buffer will follow. You should get a message the XFERbuff has been cleared. You do not need to open the XFERbuff as it is opened automatically when BHP Down, <Shift><F8> is pressed. (Step 3). (2) Give the download command " D MEMTEST.BHP " (There might be another letter after the "D" indicating a Directory on the BBS.) (3) Hit <Shift><F8> to prepare PET to receive a BHP file. XFERdnl on the command will be highlighted in red to show the XFERbuff has been opened. You will be prompted for where the file is to come from, TNC or RECVbuff. Choose TNC. You will now receive the prompt "Waiting For Header". (4) The first thing you will receive from the BBS is the Header and you will see the filename at the center of the command line. As data blocks are received, their block numbers will appear on the command line which allows you to monitor the progress of the download. (5) Do not hit any keys during the download! To abort the download use <ESC>. When the download is completed, EOF will show on the command bar. The XFERdnl on the command line will return to the non-highlighted black letters. (6) Save the file to disk with <F5>. The file in the XFERbuff has been converted from BHP format to binary as it was received. Text files can be transferred in the BHP format also but there is no advantage in doing so. (7) If the file being downloaded is long, it may be downloaded in sections. When a segment is finished downloading, SAVE it to disk with <F5>. Clear the XFERbuff and load the first segment into the XFERBuff using <F4>. Download the second segment exactly like the first and the second segment will be added to the first. If downloading all segments in one session it is not necessary to reload the previous segments into XFERbuff before downloading the next segment because the previous segments are already in the XFERbuff, BUT, If you lose contact with the BBS and have to abort, it is nice to have the segments you have received on disk and not have to repeat the entire program download another time. W0RLI Mailbox with Pack-et-term Page 23 4.15.5 BHP/Binary File Conversions The Sysop can readily convert binary (or text) files to BHP files and back again. If you have a binary program file and want to convert it to BHP in preparation for forwarding it, follow these steps: (1) Load the binary file from disk into the XFERbuff using <F4> after first clearing the buffer with <F3>. (2) Send XFERbuff with <F8> (3) Select first BHP, then RECVbuff from the Alert Boxes that appear. (4) Give filename desired when prompted. (5) Hit <Return> when prompted for "Begin Block?" and again for the "End Block?" prompt. File is converted to BHP and sent to the RECVbuff. (6) Save the BHP file to disk if you wish using <Shift><F5> and selecting the filename in the File Selector Box. The reverse process, converting a BHP to binary file is similar. With the BHP loaded into the RECVbuff (previously cleared), <Shift><F8> will bring an Alert Box which allows you to select RECVbuff as the source following which the file immediately is converted to binary form and goes to the XFERbuff which can be saved to disk with <F3> if you wish. It is convenient to remember that binary files are contained in the XFERbuff and BHP files are in the RECVbuff. W0RLI Mailbox with Pack-et-term Page 24 CHAPTER 5 - MAILBOX MODE 5.1 About the Mailbox The Mailbox portion of the program was originally written by W0RLI for IBM MSDOS and was then ported to the ST with changes. The MSDOS version employed hardware flow control (RTS/CTS) between the TNC and the computer. Since the ST does not support hardware flow control, software flow control is used quite effectively so long as it is enabled in both the TNC and ST. Enabling of XON/XOFF in the ST can be done from the RS-232 Port Configuration Menu. <CTRL><S> and <CTRL><Q> are the flow control characters. The TNC must have XFLOW ON, XOFF $13 and XON $11 for proper operation. It should be noted that although hardware flow control is not used, the modem detect line IS as a way to double check the connect state of the TNC. It is suggested the RS-232 cable be checked to be sure the data carrier detect line on pin 8 is connected. 5.2 Entering Mailbox Mode In Paragraph 3.3.1 it was pointed out that the program initially comes up in the Mailbox monitor or "on line" mode ready for any user. Either <CTRL><E> of <Undo> will cause the program to switch to the Sysop, or local, mode which is identifiedby the Sysop prompt "time, n msgs>". In this mode the Sysop has his own set of commands to interface with the BBS. Exit from the Sysop mode is by the command ye to go back to the monitor mode or <TA> to go to the PET mode. 5.3 Customizing of Program Files. Before the BBS can be utilized in the Mailbox mode, the file CONFIG.MB must be edited to include certain site specific parameters including name, QTH, file routing, etc. Two other files may also be customized, INFO.MB and FWD.MB. These are ASCII files and must be edited with a "screen editor". After modification, the resulting files should be saved back to the root directory of the program disk. W0RLI Mailbox with Pack-et-term Page 25 5.3.1 CONFIG.MB The importance of the CONFIG.MB file cannot be overemphasized as, if it is not set up properly, various program failures can occur. The file must have ALL the lines of information there as the program loads the lines by their order in the file. If one is missing, it will load the wrong line and the program will not work. It is so important, a sample file has been included as Appendix E. It has been set up for drive A:. The program files such as help.mb must have their drive paths specified. This file is specified as a:\help.mb but if you are using drive C:, replace the a: with c: and the proper entry would be c:\help.mb. All the files are similarly identified. This file is a text file that contains all site-specific parameters. Edit it to have the proper parameter for your site. The form $x is a variable text field. The "$x" is replaced by the current value for that text. $A - @ BBS of the current message. $B - Type of current message. $C - Next available message number. $D - The current date. $E - The message title. (used for RFC822 headers). $F - Name of "other port", as used in the M, U, and C commands. $G - TO of the current message. $H - Hang at end of line (suppress carriage return). Use at end of line only. DO NOT USE on lines that go to the TNC. $I - Users name from the user file. $J - Date from current msg. header. $K - Time from current msg. header. $L - Number of last message. $M - Message number from current msg. header. $N - Number of active messages. $O - Sysop's call sign. $P - FROM the current msg. header. $Q - Sysop's QTH. $R - Call in a "connect request:" from either TNC. $S - Call of the end node station connected via the slave TNC. Seen initially in "***CONNECTED to:" when the adjacent node connects, may be seen in "***LINKED to:" from the adjacent node. $T - The current time. $U - User callsign. $V - Display the software version $W - Name of the "other user" in Gateway Mode. (See $F & $S) $X - Date user last logged in. $Y - Time user last logged in. $Z - Last message number when user last logged in. $a - BBS of origination of message. $j - Date message was entered at originating BBS. $k - Time message was entered at originating BBS. $m - Message number at originating BBS. W0RLI Mailbox with Pack-et-term Page 26 The first section (to the first *** EOF) is the port configuration information, two lines per port. The first line contains the port definition, the second line is the port name. The port definition is made up of several fields, separated by blanks: Field 1: The first character is the Port ID. The second and following characters give information about the port. B - BBS only may connect. C - This port is the local console. D - File download allowed from this port. E - This port requires echo. (True only for the console) G - Gateway use is allowed on this port. I - Kick off user that connects using illegal call. L - This port requires LF after CR. M - Monitoring is allowed to this port. P - This port has a printer attached. R - Remote Sysop allowed on this port (if specified Sysop). S - This is a raw serial port (another system, terminal or printer) T - This port has a TNC with TAPR commands connected. U - File upload allowed from this port. 1 - Echo monitored packets to the console. 2 - Echo user data and forwarding to the console 3 - Echo TNC commands to the console, Field 2: Connect timeout, in seconds. Field 3: Disconnect timeout, in seconds. Field 4: Monitor timeout, in seconds. Field 5: Max. lines allowed in monitor. Field 6: Number of entries retained in J list. Field 7: Number of digipeaters allowed on connect. Field 8: Minute of the hour to attempt forwarding. Field 9: Number of command errors allowed before user kicked off. The second section (to the second *** EOF) contains the directory path definitions, three lines per path. The first line is a single character path ID, followed by "D" if downloading is allowed, and "U" if uploading is allowed. The second line is the path with trailing "\". The third line is the name of the path as shown to the user. The third section (to the third *** EOF)is the "@ BBS" translation list. Each line has two fields, the first "@ BBS" as received, the second, what it translates to. For example, to remove your own call from the @ BBS field of all messages,simply include one line with just your call on it. The fourth section (to the fourth *** EOF) is the "hold calls" list. Any message entered TO, FROM, or AT one of these calls will be held (not forwarded) until the status is changed to N by the Sysop. The fifth section (to the fifth *** EOF) is the login message. Keep it short! Maximum is 255 characters. The next line is the "BBS and Expert User" prompt. Keep it SHORT! The next line is the remote Sysop prompt. Keep it SHORT! The next line is the normal Mailbox prompt. W0RLI Mailbox with Pack-et-term Page 27 The next line is your call. The next line is your QTH. The next line is the call of your local WP server. (Leave a blank line here if you do not wish to generate updates to WP.) The next eleven lines give the routing and the filename for various files required. Be sure to specify the drive such as A:\, C:\ in the routing. Help (H) text. Information (I) text. Auto-forwarding file. Log file. "J" list file. Mail data file. Mail backup file. User file. User backup file. Mail files. BID file. The next line is the filename to put monitored calls into. The next line is the max. number of monitored calls to save. NO to not give idle time to Double DOS.(Double DOS not used on ST but EVERY line must have a response since every line of the file is read by the program). NO Z if PIPE is not present (No PIPE on ST). The next 3 lines control prompting users for information. YES to prompt user to enter his name. YES to prompt user to enter his home Mailbox. YES to prompt user to enter his ZIP or postal code. The next 5 lines control logging. (input to LOG.MB) YES to turn on logging. Only connects/disconnects are logged. NO to turn off logging Gateway events. (Gateway not supported) YES to turn on file transfer logging. YES to turn on message event logging. YES to turn on logging of local commands. The next 4 lines give the control character to use for: Kicking the user off the system. Return from "talk" mode to "monitor" mode. Interrupt and go to "talk" mode. Taking the Mailbox off-line to "Sysop mode" The next line is the prompt to "continue or quit" after a page of output. The next line is sent to the console each time a prompt is sent to the user. The next line is sent to the user after a connect request. The next line is the message to use when you break into a Mailbox session to talk to the user. The next line is the response to the user when he wants to talk to you. The next lineis the message to send when you are not available to talk to the user. The next line is the message to the console when the user wants to talk to you. W0RLI Mailbox with Pack-et-term Page 28 The next section, one line per message, contains the Gateway messages. Since Gateway is not supported in W0RLI with PET, these are not useful but must have an entry regardless. Message when Gateway is not available. Message going into unproto mode. Message when attempting a connect. Message when connect fails. Message to master TNC when connect succeeds. Message when connect attempt is aborted by user. Message to send to master when entering monitor mode. The next section, one line per message, contain the message and file prompts. Prompt for title of message. Prompt for message text. Message to send at login if user has new mail. Message list header. Observe columns if you change. Line to pre-pend to a forwarded message. Prompt to edit TO. Prompt to edit FROM. Prompt to edit @ BBS. Prompt to edit TITLE Prompt to edit lmessage status. Prompt to edit TYPE. Prompt to edit BID. Message to send to console when untangle and file empty. Message to send to console when starting an untangle. Message to send as each message is deleted with KM. Prompt to edit TO. Prompt to edit @ BBS. Prompt to edit TITLE. Prompt to edit TYPE. Message to send when a message is "not an NTS" message. Max. # of calls in BT "unread mail" lilst. Max. # of calls in forwarding "unread mail" list. YES to enable auto-kill of normal messages after auto-forward. (NO leaves the message with status set to "F"). YES to enable auto-kill of "F" type messages after auto-forward.) YES to generate a service message on KT. YES to enable the ET command. Age of a bulletin (days) when it is called old. Age of an NTS message (days) when it is called old. Age of a user message (days) when it is called old. Prompt for file text. Default user name. Message when compress user file. Header for list of user records. Prompt to delete user record. Prompt to change "expert user" flag. Prompt to change "is a bbs" flag. Prompt to change "can be a Sysop" flag. Prompt to change "exclude this call" flag. Prompt to change user call in user record. Prompt to change user SSID. Prompt to change user name in user record. Prompt to specify users TNC port. Prompt to change user path. Prompt to change home BBS call. Prompt to change ZIP or postal code. W0RLI Mailbox with Pack-et-term Page 29 The next section, one line per message, contains the error/status messages. Reminder to user that he has not entered his name. Reminder to user that he has not entered his home Mailbox. Reminder to user that he has not entered his ZIP or postal code Message for I/O error. Message for "can't find it". Message for protection violation (tried to read private msg.) Message for "file exists and you can't erase it". Message for timeout. Message for "I didn't understand the command you gave". Message for done (command completed). Message for "There ain't no such port". Message for "There ain't no such directory". Message for "No such file". Message for "No such message". Message for "Port is in use". 5.3.2 INFO.MB You may put whatever information you like in this file to display to users who use the nformation command. Usually the Sysop puts a brief description of his Mailbox equipment, software in use, hours of operation, etc. 5.3.3 FWD.MB The information in this file drives the automatic forwarding of messages received by the Mailbox which need to be forwarded to other Mailboxes to reach the destination. The forwarding procedure is automatic. The FWD.MB file provides commands for automatically connecting to target BBSs, routing lists for selecting which messages are to be forwarded and to which BBS, commands to the TNC to change parameters when required and bulletin distribution lists. If the FWD.MB list does not exist, no forwarding takes place. Since this feature is not REQUIRED to get the BBS up and running, details of the FWD.MB configuration have been included in Appendix B of this manual. 5.4 TNC Congiguration. The TNC parameters must be set correctly for the program to work properly. If you have not already set these parameters (Paragraph 2.3.2), they may be downloaded to the TNC from the appropriate .SET file on the disk. From the Sysop prompt, use the command "DA PK232.SET" (or TNC1.SET or TNC2.SET depending on your TNC). This command is interpreted as "download file PK232.SET through Port A to the TNC. 5.5 Monitor Mode. In the monitor mode, users can connect and read or leave messages, upload or download files, kill selected files, etc. To get help in what commands to use, they are shown a Command Summary from which they choose the command they want. Appendix D contains a complete listing of commands. Some of the commands are available only to the Sysop and are so identified in the command listing. W0RLI Mailbox with Pack-et-term Page 30 The manner in which the Mailbox responds to users' commands is determined largely by the statements in the CONFIG.MB file which can be readily tailored by the Sysop. Such things as user prompts, logon messages, timeout periods, forwarding schedules and many others are easily changed. Keep a copy of the original file on the distribution disk so you can always go back to the original if attempted editing does not go as planned resulting in program malfunction. 5.6 Files For Mailbox Data There are folders and files set up in the root directory of the disk to store data on Mailbox activities such as messages, calls heard,files for downloading, etc. Folders Files BBSFILES (WA Command) MAIL.DAT MAPS (WB Command) MAIL.BAK FILES (WC Command) USER.DAT AMSAT (WD Command) USER.BAK PROGRAMS (WE Command) LOG.MB ARRL (WF Command) MON.MB GATEWAY (WG Command) CALLS.MB PACKET (WH Command) BIDFILE.MB MISC (WI Command) BBSLIST (WJ Command) MAIL (Name as you wish..just so the same name is in CONFIG.MB) The MAIL folder contains the text of each message entered in the Mailbox. The message number itself, which is assigned consecutively by the program, is used as the file name within the folder. The other folder names are merely a directory so that similar files can be kept together and are optional to the Sysop by specifying the name and path in the CONFIG.MB file. 5.6.1 MAIL.DAT File This file stores data such as date, calls and message name for each message. This data, along with data from the other files, is retrieved when such Sysop commands as DL. DS, EU, etc. are executed. The backup for this file is MAIL.BAK and is updated when the GM or GR commands are used by the Sysop. It is recommended backup be done daily to insure against loss of important Mailbox records. If you should damage the MAIL.DAT file (remember you aren't supposed to remove the floppy disk during operation), you MAY be able to repair it with the file MEDIT.MB on the distribution disk. It's worth a try! 5.6.2 USER.DAT File This file stores data concerning the stations who use the Mailbox. Backup for this file is USER.BAK and is updated when the command GU is used. W0RLI Mailbox with Pack-et-term Page 31 5.6.3 LOG.MB File This file stores data from which the Sysop can get a printout of the date, time and exact nature of every connection to the Mailbox. The items to be logged are identified in the CONFIG.MB file. Each line in the log file contains an event code, the date and time, followed by further information about the event. 'C' - User connected to system. 'A' -> 'H' - A user connected on that port. 'I' - Program startup. 'L' - User was linked via the station that just connected. 'S' - "connect" from local console (sysop). 'G' - GateWay event. 'A' - Connection attempted and failed. Path shown. 'C' - Connection attempted and obtained. Path shown. 'E' - End of GateWay event, or use. 'M' - Start of monitoring. 'S' - Start of GateWay use. 'U' - Entry to unprotocol mode. 'X' - Exit. 'A' - Owner put MailBox on line. 'B' - User said good bye. 'D' - User disconnected. 'E' - Excluded user attempted connect. 'F' - User forced off by system owner. 'Q' - Owner exited from program. 'T' - Timeout, forced disconnect. 'F' - File event. Command line shown as user entered it. 'M' - Message event. Message number always shown. 'C' - Message copied. 'E' - Message header edited. 'F' - Message forwarded. Connect path shown. 'FE' - End of forwarding session. 'FR' - Start of reverse forwarding in forwarding session. 'FS' - Start of forwarding session. 'K' - Message killed. 'L' - Message headers listed. 'M' - Message created from file. 'R' - Message read. 'S' - Message sent. W0RLI Mailbox with Pack-et-term Page 32 5.6.4 MON.MB File This file holds a list of calls heard during the current session and is accessed by the JA command. 5.6.5 CALLS.MB File This file holds a record of ALL calls which the Mailbox has heard but is not limited to the current session. 5.6.6 BIDFILE.MB File This file holds a record of all bulletins received and their BID (Bulletin Identification) numbers. The date received by the system is also rrecorded. When a bulletin is received, it is checked against the BIDFILE to see if it has been received previously. 6.0 PRTLOG.TTP Log File Analyzer On the distribution disk is the file PRTLOG.TTP which, when run with the parameter " -L LOG.MB" will display information from the LOG.MB file to the console. Such things as the date/hour, % of time the Mailbox was on the air, % of time actually in use, etc. are displayed which aids the Sysop in determining exactly what has been happening on his BBS. Omitting the -L will display a summary of the data. Entering "-L LOG.MB > MYFILE.LOG" will send the detailed log info to the disk file MYFILE.LOG rather than the console. Again, omitting the -L will send a summary to the disk file. W0RLI Mailbox with Pack-et-term Page 33 APPENDIX A - BLOCKED HEX PROTOCOL PACKET CONSTRUCTION BLOCKED HEX PROTOCOL (BHP) is a format for transferring binary files via packet radio. It is able to do this in the TNC's converse mode, as all characters in a BHP packet are in ASCII code any may be transferred with 7 bits. BHP may be used to send files to their destination via the existing W0RLI BBS system, in whole or in pieces. The BHP Header Packet The first packet sent during a BHP session is the "Header", which contains the vital statistics of the file being transferred. Look at this sample header packet and identify its component parts. ^filename.txt*000CB*000000*000000~7E The first byte of the header is ^ which is ASCII code $5E, and is the marker meaning "filename in ASCII follows". After the filename, an "*" follows, ASCII $2A, and marks the beginning of the 5 Hex digits which carry the total length of the program of which a portion is being sent. Note that you may be sending only a small portion of a large program, but the entire length of the complete program is sent during each transfer. This information is uded by the downloading BHP station to set its transfer buffer to the proper size. After the file length, another "*" follows and marks the beginning of 6 Hex digits which carry the Load address of the program. In the sample header shown we are using all zeroes because the Atari ST uses relocatable code and therefore does not care about the Load address. After the Load address, another "*" follows and marks the beginning of 6 Hex digits which carry the Execution address, which is also not used on the ST and therefore is 000000 in our example. After the Execution address, the "~" or ASCII $7E follows, which marks the start of 2 Hex digits which carry the checksum for the Header. The checksum is an 8 bit sum of all the bytes in the Header. Overflow beyond 8 bits is ignored. This checksum is critical, causing the receiving BHP computer to abort if not correct! W0RLI Mailbox with Pack-et-term Page 34 The BHP Data Packet The data packets represent 50 bytes of binary data, in a special Hex format. Please note that the final packet of the binary file may have less than 50 bytes. Look at this sample of BHP data packet and identify its key components. {000120616E20417461726920535420436F6D707 57465720D52756E6E696E67205041434B2D45542 D5445524D2076657273696F6E~77 The { or ASCII $7B marks the beginning of a BHP data packet. The next 4 digits are a Hex representation of the data packet's block number, which gives the relative address of the data within the transfer buffer. Blocks are numbered 0 to n, and therefore it is simple to calculate where in the buffer that the data is to reside. The formula: Buffer Address = (block number * 50) The example block would begin loading at the address 50 in the transfer buffer. Each pair of characters that follow will represent one binary byte in Hex format. The ~ or ASCII $7E, once again marks the beginning of the checksum, the checksum being the 8 bit total of all bytes in the current block. Unlike the Header, it is not necessary to abort the download if a checksum error occurs, but simply mark the block as bad for retransmission later. At the end of any transfer session, the } or ASCII $7D is sent to signal that the current BHP transfer session is done. This is not to say that the entire file has been transferred, but only that the current transfer section is complete. W0RLI Mailbox with Pack-et-term Page 35 APPENDIX B - AUTOMATIC MESSAGE FORWARDING The forwarding process is automatic. The FWD.MB file provides commands for automatically connecting to target BBSs, routing lists for selecting which messages to forward and to which BBS, commands to the TNC to change parameters when required and bulletin distribution lists. If the FWD.MB file does not exist, no forwarding takes place. Additional explanation of what the RLI forwarding protocol is all about may be helpful. The following is an attempt to put down in detail what the W0RLI Mailbox expects as user input, and the variations that will be accepted by the Mailbox code. Forwarding works by the simple means of the forwarding Mailbox acting as if it were a user of the target Mailbox. Thus, it will use the "S" command to enter the message in exactly the same way that a user does. The "S" command takes the form: "S"["x"] TO ["@" BBS] ["<" FROM] The "x" is an optional message type character. The fields are delimited by any number of spaces or tabs. Upper case or lower case may be used. TO, BBS, and FROM may be up to six characters. If a trailing "-" and ssid are given, it is thrown away. The "@ BBS" and "< FROM" fields are optional, and may occur in any of the 4 possible combinations. After receiving the "S" command, the MailBox prompts for message title. The prompt is on one line, ending with CR. The message title is one line, ending with CR. The title is truncated to 80 characters by the MailBox. After receiving the message title, the MailBox prompts for the message text. The prompt is on one line, ending with CR. Message text is a string of ASCII characters, ending in control-z. The station doing the forwarding simply disconnects once it has passed all of its messages. Note that the MailBox prompt is identified by it's terminating ">". The BBS also supports the use of BIDs (Bulletin Identifiers) and to use them, it will, when it recognizes a similarly programmed BBS, enter into an exchange with said BBS. This is according to the protocol developed by WA7MBL. W0RLI Mailbox with Pack-et-term Page 36 A BID capable BBS is recognized by its sending a field beginning with a '[' and ending with a ']'. In addition, in the field is at least one '-'. Anything following the LAST '-' is taken to identify features available on that BBS. The exchange from this BBS is: [GYQ-CBBS4.5-$] When the BBS is connected to, it sends [GYQ-CBBS4.5-$], and if it receives [anything-$], it goes into its MBL-like mode. It then gives you a prompt and waits for your next Send command. If you send something like S ALL $BID001, it checks to see whether it has received this BID before. If not, it sends: OK - Snd # 1234 (will be message #1234) The sender then sends the title followed immediately by the message text. If it has that BID, it will send: NO- Already have it. A new '>' follows. The distant BBS will then proceed to the next message. Whether the connecting station is a BBS or not, if a message comes in addressed to something other than a real callsign (like ALL), it is assigned a BID by a parsing routine. It finds the BBS of origin, and the message number on that BBS, and gives it a BID based on BBSCALL_msg# ... It will then check the BIDfile and if the message is present, it will mark it held pending operator intervention (presumably you already forwarded the message). This works with any system that has the terminal -$ in its [-$] field. Several people have suggested using zip codes for routing identifiers. There are many possible ways to do this. I outline two suggestions. These two routing schemes are compatible, and can co-exist on the network at the same time. Two features are required in the BBS code to support these routing schemes properly: 1. Wildcard capability in the route table destinations. 2. "@ BBS" replacement. Either of these schemes will help users. They no longer need to know the callsigns of all the BBS in the world. Users need only know the state, province, region, or zip code of the message destination. 1) Zip code routing for NTS traffic. Use the form "ST nnnnn @ NTSxx" where nnnnn is the destination zip code and xx is the state, province, or region identifier. In route tables far from "xx" only the path toward "xx" need be known. Once the message reaches "xx" the receiving BBS should remove the "@ BBS" designator. Routing will then continue using the zip code. 2) Zip code routing to humans. Use the form "SP call @ zip" or "SP call @ xx". These forms are not ideal. What should be used is a form with 3 address fields. None of the BBS codes support this yet. The ideal form for routing of personal messages is "SP call @ zip @ xx". This routing scheme then would follow the NTS routing scheme in 1). Since we do not have a three address scheme, the first and second forms in 2) would be the best available. W0RLI Mailbox with Pack-et-term Page 37 Some examples of routings that could work now: ST 95060 @ NTSCA This message would end up at kb6irs or n6iya for delivery by NTS. SP W0RLI @ CA This message would go to any of the eight California HF BBS. At the California HF BBS the "@ CA" would be removed and routing would continue in the normal manner to W0RLI. SP VE3FXB @ ON The same idea as the previous message. SP VK2AHX @ VK Again, the same idea. Note that stations that do not have a path to VK need only keep the single identifier "VK" in their route tables. SP W0RLI @ 95060 With schemes like this, and the use of wildcards in the route tables and "@ BBS" replacement tables, only a very few identifiers are required to cover the entire U.S. If this message had originated, for example, in New England, the BBS in New England need only have "9*" in it's route table. Once the message reached, for example, KD6SQ, he would have to have several identifiers. "95*" would send the message from So. Cal. to No. Cal., where the "@ BBS" would be removed. It would then be forwarded directly to W0RLI, since W0RLI is known to all BBS in No. Cal. CONFIGURATION OF FWD.MB FILE FOR MESSAGE FORWARDING (1) Command Scripts Command scripts contains C, R and S items and precede the F or G routing lilst that uses it. A C item gives the connect command to send to the local TNC. An example is CC W4ABC which obviously would connect with W4ABC. An S item is a line to send to the station connected to. An example would be SC W4XYZ. If station W4ABC in the above example was using NET/ROM, sending C W4XYZ would complete the link to W4XYZ through W4ABC An R item is an expected response. If we connected to W4XYZ in the manner outlined above, the NET/ROM station would send an acknowledgment of the connection in the form "ORL1:W4ABC-1} Connected to W4XYZ". This expected response would be included in the FWD.MB file as "RORL1:W4ABC-1} Connected to W4XYZ". The responses of your local stations may be slightly different but the point is to specify the EXACT response expected and if it is not received, the message transfer will abort. Digipeaters can be included in the path. The complete command script for the above case would be: CC W4ABC SC W4XYZ RORL1:W4ABC-1} Connected to W4XYZ *** EOF W0RLI Mailbox with Pack-et-term Page 38 (2) Routing Lists Routing lists are placed immediately after the command script in the FWD.MB file. These lists may be E, F, G or H lists which are lists of stations for whom mail is to be forwarded. The stations are grouped by the call of the Mailbox to which the messages are to be forwarded. Each list has a header line, any number of call signs or sublists, and the list terminator (*** EOF). "G" List - Use for conventional forwarding. All BBS systems will respond. "F" List - Use with BBS systems that support reverse forwarding which returns any messages it may be holding for the calling BBS. "H" List - Same as "F" except the probe for reverse forwarding will occur even if calling BBS has no messages to forward. "E" List - Acts like a "G" list except forwarding is disabled but will respond if another BBS requests reverse forwarding Following the typical routing list below is a listing of the information contained in each column. GF0023C KA6IQA KA6IQA W6FWO *** EOF Column Data 1 "E", "F", "G" or "H" type list. 2 Port identifier. "A", "B" etc. 3&4 Hour to activate forwarding to this station, in this case, 00:00 (midnight) The minute of the hour is specified in the CONFIG.MB file. 5&6 Hour to deactivate forwarding. (23:00) 7+ Call sign of the Mailbox forwarded to. (3) TNC Parameter changes - "P" Lists "P" lists are commands sent to the TNC to change TNC parameters for a particular message forward attempt. Because it might be desirable to increase the number of retries, for example, if a marginal path is anticipated, a "P" list could preceed a particular "G" list. If a "P" list is used, another one should be used at the end of the FWD.MB file to return to the original parameters before going back to normal BBS operation. PA0004 RETRY 3 FRACK 7 *** EOF W0RLI Mailbox with Pack-et-term Page 39 (4) Bulletin Distribution Lists If a message has a destination Mailbox specified, then that designator may also be used as the name of a distribution list. When the message is entered, the message path (normally \MB\MSGS\) is checked for a file with the same name as the designator and an extension of .DIS. If the file is found, then the message will be forwarded to ALL the destinations found in the file. One destination per line, 12 destinations maximum. As an example, assume a local net named SFLNET had 3 members to whom you wished to forward a bulletin. They could be forwarded to the BBS designated SFLNET if you have a file named SFLNET.DIS in the messages directory containing the call signs of the 3 members. A message sent as " SB ALL @ SFLNET " would be forwarded to all three stations in the SFLNET.DIS file. The message is not forwarded in any particular order. If a station is busy then the Mailbox will try again the next hour. An "L" command to LIST a message with a distribution list shows the status of forwarding to each station on a second "cc:" line. The calls to which the message have been sent have an asterisk before them. (5) Wildcards When the designator in FWD.MB file is compared to the TO or @ BBS call, the characters "?" and "*" appearing in the designator act as "wildcards". "?" will match any character. "*" causes the remaining characters to match. For example, using ZIP code routing to route all South Carolina NTS traffic to WA4SZK, you would put "NTS4*" or "4*". Any message sent to a destination starting with "NTS4" or "4" would route to WA4SZK. WA4SZK could then continue the routing breakdown by forwarding "NTS41* or "41*" to one station, "NTS42*" or "42*" to another, etc. (6) Sublists At any place in the FWD.MB file you can refer to another file. In effect, what happens is that the contents of the sublist are treated exactly as if they were in the FWD.MB file. This feature is very useful when you have several alternate paths to a given location. FWD.MB need only contain the connect information for the different paths. You can refer to a single file that contains the list of calls for forward. A sublist is given by a line starting with "@". The rest of the line is the device, path, and file name of the sublist. For example: CC N4CHV V N6MPW-1 GS0023C N4CHV N4CHV N7FSP @C:\MB\BBS\HF111.FWD @C:\MB\BBS\SILICON.FWD *** EOF CC W6CUS-1 V W6AMT-10 GD0023C W6AMT NI6A @C:\MB\BBS\SILICON.FWD *** EOF W0RLI Mailbox with Pack-et-term Page 40 Following is an example of the FWD.MB file at WA4GPF: CC ORL7 SC KB4LB GA0018C KB4LB KB4LB N4JTS *** EOF CC ORL7 SC JAX7 RORL7:WD4HIM-7} Connected to JAX7:W5HUQ-4 SC WD4BIW RJAX7:W5HUQ-4} Connected to JAX7:W5HUQ-4 FA0012C WD4BIW WD4BIW JAX *** EOF CC ORL7 SC GNV9 RORL7:WD4HIM-7} Connected to GNV9:KD4SR-5 SC WD4EPK RGNV9:KD4SR-5} Connected to WD4EPK FA0018C WD4EPK WD4EPK KD4SR *** EOF CC ORL7 SC DAB5 RORL7:WD4HIM-7} Connected to DAB5:N4EEB-5 SC KB4T RDAB5:N4EEB-5} Connected to KB4T FA0018C KB4T KB4T EAST *** EOF CC ORL7 SC WB4HYP RORL7:WD4HIM-7} Connected to WB4HYP FA0018C WB4HYP WB4HYP *** EOF CC ORL7 SC OCF3 RORL7:WD4HIM-7} Connected to OCF3:KD4SR-9 SC K4OZS ROCF3:KD4SR-9} Connected to K4OZS GA0018C K4OZS K4OZS *** EOF There is no limit to the number of lists or the number of calls in each list. Your Mailbox will do the connect and send the message onward. It will either delete it or mark it with an "F" status depending on the setting of the YES/NO (Kill on forward) flags in CONFIG.MB. Auto forwarding is attempted each hour at the minute specified in CONFIG,MB or when you use the "X" menu item. W0RLI Mailbox with Pack-et-term Page 41 The special call "*" (a single *) can be used to force the forwarding of all mail not addressed to the system owner. This could be used by someone who would like to run the software, but would not like to maintain an active Mailbox. They would get all their own mail locally, but any mail deposited onto their system would be automatically forwarded. The forwarding of messages counts on the remote Mailbox behaving correctly. It must have a menu with " > " at the end of the last line. The command for sending messages must have the form "Sx call". It must prompt for message title, and then prompt for message text. Message text is terminated by ^Z. HOW TO MAKE MULTIPLE MESSAGES : (W0RLI C BBS 4.4) (This information provided by Hasan, N0AN.) (Updated by VE3GYQ 88-01-25) There are TWO METHODS, TWO TYPES OF FILE LISTS and TWO RESULTS: CREATE MULTIPLE MESSAGES FROM A FILE ON DISK USING .LST LISTS CREATE MULTIPLE MESSAGES FROM THE KEYBOARD USING .LST LISTS CREATE A SINGLE MESSAGE ADDRESSED TO MANY FROM A FILE USING .DIS LISTS CREATE A SINGLE MESSAGE ADDRESSED TO MANY FROM KEYBOARD USING .DIS LISTS 2 METHODS = FROM A DISK FILE OR FROM A KEYBOARD 2 TYPES OF FILE LISTS = .LST and .DIS lists. 2 RESULTS = MULTIPLE MESSAGES with INDIVIDUAL ADDRESSES or a SINGLE MESSAGE with MULTIPLE ADDRESSES. =========================================================================== == METHOD 1: CREATE MULTIPLE MSGS FROM A FILE ON DISK USING .LST LISTS 1. Create a file NOT USING a .DIS extension that contains a list of the BBS commands for each of the destination BBS's you want a copy of the message to go to. Save this file to the \MB directory. EXAMPLE: FILE CONTENTS OF IANET.LST located in \MB directory: sb all @ wa0jfs sb all @ ki0q sb all @ nf0n sb all @ ai0z sb all @ k0boy sb all @ wb7dch 2. COMMAND SYNTAX: MM LIST \PATH\FILENAME.EXT EXAMPLE: MM IANET.LST \MB\AMSAT\NEWS0803.87 Creates 6 separate messages in the exact form of IANET.LST, SB ALL @ CALLThe messages go as bulletins to all @ wa0jfs, ki0q, nf0n, ai0z, etc. -------------------------------------------------------------------------- W0RLI Mailbox with Pack-et-term Page 42 METHOD 2: CREATE MULTIPLE MESSAGES FROM THE KEYBOARD USING .LST LISTS 1. .LST LIST ALREADY CREATED 2. COMMAND SYNTAX: SM LIST EXAMPLE: SM IANET.LST You will be prompted to enter a subject, then text terminating in CTRL-Z. The result will be INDIVIDUAL MESSAGES created for each call on the IANET.LST. --------------------------------------------------------------------------- METHOD 3: CREATE A SINGLE MSG ADDRESSED TO MANY FROM A FILE USING .DIS LISTS 1. Create a file like QST.DIS that contains just the call signs of those on the distribution list. Save this file to the \MB\MSGS subdirectory. FILE CONTENTS OF QST.DIS located in \MB\MSGS directory: WD0EMI WA0JFS KI0Q K0CNM 2. SYNTAX: MF ALL \path\filename @ BBS (Create multi-message from a file) EXAMPLE: MF ALL \MB\AMSAT\NEWS0810.87 @ QST This command will create a multiple message from the file NEWS0810.87 located in the \MB\AMSAT subdirectory. The message will be sent to all of the stations listed in the QST.DIS file. The QST.DIS file must be located in the \MB\MSGS subdirectory and must ONLY contain a simple list of the calls you want distribution to go to. --------------------------------------------------------------------------- --- METHOD 4:CREATE A SINGLE MSG ADDRESSED TO MANY FROM KEYBOARD USING .DIS LISTS SYNTAX: SM ALL @ BBS (Create multi-msg from keyboard) EXAMPLE: SM ALL @ QST This command will result in a prompt for a SUBJECT and then prompt you to enter the text and terminate the text with Ctrl-Z. After you type the CTRL-Z, a multiple message will have been created to each of the calls in your QST.DIS list. W0RLI Mailbox with Pack-et-term Page 43 DIFFERENCES BETWEEN THE USE AND OPERATION OF .LST and .DIS distributions: -------------------------------------------------------------------------- A MULTIPLE MESSAGE created using a .LST list will produce SEPARATE MESSAGES on your BBS to each call in the distribution list. A MULTIPLE MESSAGE created using a .DIS list will produce ONE MESSAGE, with a multiple header under it e.g. cc AI0Z, KI0Q, WA0JFS etc. SUMMARY: MM IANET.LST \MB\AMSAT\FILENAME.EXT (IANET.LST in \MB directory) SM IANET.LST (KEYBOARD ENTRY) MF ALL \MB\AMSAT\FILENEAME.EXT @ QST (QST.DIS in \MB\MSGS directory) SM ALL @ QST (KEYBOARD ENTRY) In all cases, a unique BID may be specified as the last argument of the line, prefaced by a $: MM IANET.LST FILENAME.EXT $N0AN001 If a message is entered as a bulletin (addressed to something other than a real callsign, and NO BID is specified, a BID will be generated for that message automatically based on the BBS callsign, and the message number of the BBS. Thus, a message sent to ALL on N0AN that is message 1005 has a BID of N0AN_1011 (note the underscore). W0RLI Mailbox with Pack-et-term Page 44 APPENDIX C - WP (White Pages) PROCEDURES WP stands for "white pages" and is a directory system for packet radio mailboxes. It allows remote query and updating of a database that lists the users of RLI-compatible mailboxes and their home bbs. To use the program, a message is sent to "WP" at WD6CMU. The message can have several lines (a single message can contain several queries/updates), but each line must have one of the following formats: <callsign> QTH? <callsign> QTH <mailbox> DE <callsign> @ <mailbox> The first form is a query and will return the home bbs of the person with the given callsign. The second form adds or changes the entry for the given callsign, storing his home mailbox with his callsign. The third form provides a return address for the requested information. If the message does not contain a line of the third form, the WP program will try to get the return address from the forwarding headers. This will work as long as the mailboxes in the forward path use the NK6K format for forwarding headers. Replies will be sent to the originating station at the mailbox specified as described above. The reply will be generated a few minutes after the message is received at WD6CMU. Currently, the WP program is run every 15 minutes, so that is the maximum wait for a reply. Of course, queries sent from other mailboxes will have to make their way through the forwarding system, as will the reply. For example, suppose you wanted to find out where KE6AD was located? You would send a message to WP like this: Msg# TR Size To From @ BBS Date/Time Title 2005 PN 11 WP WD6CMU 0319/1207 A query ke6ad qth? Notice that case is insignificant within the message. If the station was not on file, WP would send you a reply that looked like this: Msg# TR Size To From @ BBS Date/Time Title 2006 PN 74 WD6CMU WP 0319/1207 Reply to WP query KE6AD no record, sorry. 73 DE WP @ WD6CMU W0RLI Mailbox with Pack-et-term Page 45 If you happened to know that KE6AD was at N7EQN, you could tell WP that. Let's say you also wanted to look up N7EQN. The message would look like this: Msg# TR Size To From @ BBS Date/Time Title 2007 PN 27 WP WD6CMU 0319/1208 ke6ad qth n7eqn ke6ad qth n7eqn n7eqn qth? The reply from WP would be: Msg# TR Size To From @ BBS Date/Time Title 2008 PN 85 WD6CMU WP 0319/1208 Reply to WP query KE6AD QTH N7EQN QSL TNX N7EQN QTH N7EQN Redwood City, CA (SKYWARN) 73 DE WP @ WD6CMU The database is in a growing state so it may not contain the callsign you're interested in. If you wish to add an entry, please make sure that the information is accurate. W0RLI Mailbox with Pack-et-term Page 46 APPENDIX D - MAILBOX COMMANDS The following listing gives the commands used to access the various functions of the Mailbox. Some are only available to the Sysop. In the left column are the identifiers "?", "#" and "!" ? - Descriptions following the command are displayed when brief help is requested with the <? sp x> command. (where x is the command queried) # - Descriptions following are displayed when extended help is requested with the <H sp x> command. ! - Commands available to Sysop. Some are not available to user. ? _ MailBox Command Summary (?,B,C,D,H,I,J,K,L,M,N,P,R,S,T,U,V,W) Type ?, a space, and a letter for help on a specific command. For example: ? R for information on the R command. Type ? ? for a one line summary of each command. For more detailed help, type H, space, and the first letter of the command for which help is wanted. # _ For help on a specific command, enter H x where x is the command for which you need help. For example, H R will give complete help for the READ command. ? x will give you a brief explanation of command x. Message commands: (K)ill (L)ist (R)ead (S)end File commands: (D)ownload (U)pload (W)hat GateWay commands: (C)connect (M)onitor Misc commands: (B)ye (H)elp (I)nfo (J) Who? (N)ame (P)ath (T)alk to sysop (V)ersion Further info: (@) At BBS To get a complete help listing type H ?. It is very long! W0RLI Mailbox with Pack-et-term Page 47 # @ Enter this symbol to indicate the BBS of the addressee, for proper forwarding of the message to its destination. The message, no matter to whom addressed, will be forwarded to the "@ BBS" location. ! ! SYSOP commands: ! ! @ - Switches remote user between the standard remote commands ! and the remote sysop commands. User must have sysop privilege. ? B ye - Log off the MailBox. # B ye - Log off the MailBox. Simply disconnecting has the exact same effect. ? C <C> - Connect to a CALL or port. !<C>lock YYMMDD HHMM - Set the clock. # C <Cp> - You will be connected to port p, and anything you send will be echoed out that port in unproto mode. <C> CALL - Connect to CALL, using the path that CALL last used to connect to the MailBox. <Cp> CALL - Connect to CALL, using port p. Digipeater routing may also be given. Examples: CA W0RLI V N6MPW-1 C KB6IRS ! ! SYSOP commands: ! !<C> YYMMDD HHMM - Set the clock. ! !<CM CALL #> [@ bbs] [< call] - Copy message. (See "M" command) W0RLI Mailbox with Pack-et-term Page 48 ? D <D>ownload - Read a file from the MailBox. # D <Dd filename> - Download a file from MailBox. d is the path identifier. ! ! SYSOP commands: ! !<D filename> - Download a file. ! Full device and directory path may be given. !<DL> - List local users. !<DM> - List users marked as bbs. !<DS> - List sysop users. !<DU> - List all users. !<DX> - List excluded users. ! For the above commands, if a file name is given as argument, ! the list is put into the file as well as displayed on the screen. ! !<DW> - Send WP any new NH info. !<DW A> - Send WP all NH info. ? E <ET #> - Edit NTS traffic message header. ! Edit various things. Use H E for details. # E <ET #> - Edit the TO, @ BBS, TITLE, or TYPE of an NTS traffic message. ! ! SYSOP commands: ! !<E #> - Edit a message header. !<EP p> - Edit port parameters for port p. !<ES> - Edit system parameters. !<EU> - Sweep through all users. !<EU CALL> - Edit a user record. ? F ! Make a file from a message. Use H F for details. # F ! ! SYSOP commands: ! !<Fd # FILE opt> - Make a file from a message, in directory area d. !<F # FILE opt> - Directory path and file name. ! Opt: A - Append to existing file. W0RLI Mailbox with Pack-et-term Page 49 ? G !<GM> - Untangle the mail file. !<GR> - Untangle the mail file, renumber messages from 1. !<GU> - Untangle the user file. # G ! ! SYSOP commands: ! !<GM> - Untangle the mail file. !<GR> - Untangle the mail file, renumber messages from 1. !<GU> - Untangle the user file. ! ? H <H>elp - Display full explanations of MailBox commands. <?> - Display one-line explanation of MailBox commands. # H <H> - Gives a summary of the Help Subsystem. <H x> - Gives a detailed explanation of command x. <H ?> - Gives a detailed explanation of all commands. <?> - Gives a list of MailBox commands. <? x> - Gives a summary of command x. <? ?> - Gives a summary of all MailBox commands. ? I nfo - Information about station facilities. # I nfo - Gives a paragraph on the hardware, software, and rf facilities of this MailBox station. ? J <J> - Who? - Gives info on stations heard or connected. # J <Jp> - Where p is a port identifier. Gives a short list of stations recently heard on that port. The special port L shows calls of stations recently connected to the MailBox. W0RLI Mailbox with Pack-et-term Page 50 ? K <K>ill - Kill a message by number. # K <K #> - Kills message number #. <KM> - Kills all messages addressed to you, that you have read. <KT #> - kills an NTS message and generates a return 'service message' ! ! SYSOP commands: ! !<KF> - Kills all "FF" messages. !<KF CALL> - Kills all "FF" messages to CALL. !<KO> - Kills all "old" messages. !<KY> - Kills all messages that have been read. !<KY CALL> - Kills all messages to CALL that have been read. ! Note that plain K will kill ANY message. ? L <L>ist - List messages entered since you last logged in. # L Generally lists messages in reverse order, newest to oldest. "Private" messages not to or from you will not be listed. <L>ist - Lists all new messages since your last log-in. <L?> - Lists only new messages of type '?'. <LM> - "List Mine". Lists all messages TO or FROM you. <L #> - Lists messages back to and including number #. <LL #> - Lists the last # messages. Common Message type assignments: A - ARRL Bulletins. B - General Bulletins. F - SPECIAL - Message is not "Killed" upon being forwarded. M - RESERVED for "Mine"- may not be used. P - Private messages - will not be listed in normal directory. T - NTS traffic Some special List commands are: L> call - Lists all messages to this callsign. L< call - Lists all messages from this callsign. L@ call - Lists all messages addressed at this BBS callsign. LF - Lists all messages that have been forwarded. LH - Lists all held messages. LO - Lists all "old" messages. LY - Lists all messages that have been read. W0RLI Mailbox with Pack-et-term Page 51 ? M <M>onitor - Watch the packets on another port. # M <M>onitor - Show what ports are available on this MailBox. <Mp> - Watch the packets on port p. ! ! SYSOP commands: ! !<M CALL FILE> - Make a message from a file. See S command. !<MM listfile textfile> - Make multiple messages from a file. See SM command. ? N <N xxxx> - Enter your name into user database. <NE> - Toggle your "expert user" status. <NH xxxx> - Enter your 'Home BBS'. (Aids in routing mesages to you.) # N <N xxxx> - Enter your first name into user data base. <NE> - Toggle your "expert user" status. <NH xxxx> - Enter your 'Home BBS'. (Aids in routing mesages to you.) ! ! SYSOP commands: ! !<N FROM TO> - Change file name. !<NN P CALL TIMEOUT FILE> - Collect NET/ROM routing info, ! from CALL on port P, use timeout TIMEOUT, put in file FILE. ? P - Show the path that CALL last used to connect. # P - Show the path that CALL last used to connect. ? Q !<Q> - Quit (return to DOS). # Q ! !<Q> - Quit (return to DOS). ! ? R <R>ead - Read a message. # R <R #> - Read message number #. <RH #> - Read message number #, showing all routing headers. <RM> - "Read Mine". Read all your unread messages. W0RLI Mailbox with Pack-et-term Page 52 ? S <S>end - Send a message. # S <S? xxxx @ yyy> - send message type '?' to station 'xxxx', at optional BBS 'yyy'. The MailBox will prompt for title and ask you to enter text. End text entry with a ctrl-Z. "?" is an optional "type" of message. They include: A - ARRL Bulletins. B - Bulletins. General information to all. F - Forwarding - message will not be 'killed' upon automatic forwarding. Copies are maintained at all stations along the path. P - Private. Only the addressee can read or list this type. T - NTS Traffic ! ! SYSOP commands: ! !<S> - With Bulletin distribution. ! If there is a file in the \mb\msgs directory with name ! same as the @ BBS and extension .DIS, then the message ! will be sent to all the calls in the list. Max 12 calls. ! !<SM filename> - Send Multiple. ! The file is opened, and multiple messages are created using ! the commands in the file. Message qualifiers, @, <, and ! bulletin distribution lists are supported. Each line in the ! file is a command exactly as you would have given it to ! the MailBox. ? T <T>alk - Chat with the Sysop. # T <T>alk - Chat with the Sysop. Any command or Return before the request times out will return you to the normal MailBox prompt. ! ! SYSOP commands: ! !<Tp> - Go to terminal mode on port p. !<Tp FILE> - Go to terminal mode on port p, open save file. ? U pload - Send a file to the MailBox. # U - Upload a file to the name given. For example: UC WESTNET.BBS Reject will occur if filename already exists. W0RLI Mailbox with Pack-et-term Page 53 ? V <V>ersion - Show what version of the MailBox is running. # V <V>ersion - Show what version of the MailBox is running. !<V FROM TO> - Copy file. ? W <W>hat - List the file directory of the MailBox. # W <W>hat - Gives a list of directory areas available on the MailBox. <Wd> - Gives a list of the files in directory area d. <Wd ffff.xxx> - Gives a list of files in directory area d that match the given file specification. ! !<W> - Any path and filespec allowed. ? X ! Trigger an auto-forward. Use H X for details. # X ! !<X> - Trigger an auto-forward. !<XI> - Auto forward, ignore time window. !<X CALL> - Do it only for CALL. !<XI CALL> - Do it only for CALL. ! ? Y !<YF file> - Give name for forwarding file to use. # Y ! !<YF file> - Give name for forwarding file to use. ! ? Z !<Z FILE> - Delete the file. # Z ! !<Z FILE> - Delete the file. Full path name allowed. !<Zd FILE> - Delete file from directory area d. ! W0RLI Mailbox with Pack-et-term Page 54 APPENDIX E - TYPICAL CONFIG.MB FILE ATMRIUD 300 20 500 100 20 3 55 5 145.07 Mhz. LCEUD 100 20 500 100 20 0 60 20 Connected *** EOF AD A:\bbsfiles\ BBS Related files Download only area. BD A:\maps\ Map files Download only area. CU A:\files\ USER UPLOAD area Upload only area. DD A:\amsat\ AMSAT/OSCAR Related files Download only area. ED A:\programs\ Program files Download only area. FD A:\arrl\ CRRL/ARRL Related files Download only area. GD A:\gateway\ Latest Issues of Gateway Download only area. HD A:\packet\ Packet Related files Download only area. ID A:\misc\ Miscellaneous "Junk" Download only area. JD A:\bbslist\ State or Country Listing of BBSs Download only area. *** EOF wa4gpf *** EOF no *** EOF Hello $I, Welcome to the $O MailBox from $W in $Q Last logged at $Y on $X. Type H for help, L to list new messages. *** EOF WA4GPF BBS> $T, $N msgs>$H $U de $O: at $Tz on $D B,C,D,H,I,J,K,L,M,N,P,R,S,T,U,V,W,? > WA4GPF Orlando, Fla WD6CMU A:\help.mb A:\info.mb A:\fwd.mb A:\log.mb W0RLI Mailbox with Pack-et-term Page 55 A:\mon.mb A:\mail.dat A:\mail.bak A:\user.dat A:\user.bak A:\mail\ A:\bidfile.mb A:\calls.mb 500 (Max # calls to save in calls.mb) NO (DoubleDOS present) NO Z (PIPE not used) YES (Prompt user to enter name) YES (Prompt user to enter home bbs) YES (Prompt user to enter ZIP) YES (Turn on logging) YES (Log GateWay events) YES (Log file transfers) YES (Log message events) NO (Log local events) F (Control char to kick user off system) E (Control char to return from talk mode) E (Control char to interrupt user and talk) E (Control char to interrupt idle MailBox and get local menu) < Any key to continue, Q to quit. >$H $S ($W) using the MailBox on $F $R tried to connect. Please stand by, $W would like to talk to you. Hang on one minute, I will page $W. $W did not answer, you might leave a message in the MailBox. $S ($W) would like to talk to you. The GateWay is not available. You are linked to $F ^W returns to prompt. Attempting the connection on $F ^W will abort. Connection not established. Connection established. ^W to disconnect. Connection aborted. You are listening to $F Type anything to return to prompt. Enter title for message: Enter message, ^Z (CTL-Z) or /EX to end, it will be message $C You have new mail: Msg# TR Size To From @ BBS Date/Time Title R:$J/$Kz @:$O $Q #:$M O:$P EDIT: New TO or <cr> to retain:$H New FROM or <cr> to retain:$H New @ BBS or <cr> to retain:$H New TITLE or <cr> to retain:$H New F/H/N/O/Y or <cr> to retain:$H New TYPE or <cr> to retain:$H New BID or <cr> to retain:$H Mail file empty. Untangling Mail. *** Killed message $M New TO or <cr> to retain: New @ BBS or <cr> to retain: New TITLE or <cr> to retain: New TYPE or <cr> to retain: *** Sorry, that is not an NTS traffic message. W0RLI Mailbox with Pack-et-term Page 56 40 (Max calls in BT list) 40 (Max calls with msg to fwd) NO (Kill regular message after forward) NO (Kill type F message after forward) NO (Generate svc msg on KT) YES (Enable ET command) 21 (Age of bulletin message when marked as stale, days) 2 (Age of NTS message when marked as stale, days) 10 (Age of user message when marked as stale, days) Send the file, ^Z (CTL-Z) to end. ?_Name Compressing the user file. Call Date Time Logd Msg Hm BBS I PLBEDSK Name Zip EDIT: Y delete, Q quit, CR continue :$H Y change EXPERT USER :$H Y change IS A BBS :$H Y change Can be SYSOP :$H Y change EXCLUDE :$H New CALL <cr> to retain:$H New SSID <cr> to retain:$H New NAME <cr> to retain:$H New PORT <cr> to retain:$H New PATH <cr> to retain:$H New HOME BBS <cr> to retain:$H New ZIP <cr> to retain:$H *** N (name) to enter your name. *** NH (call) to enter your home BBS. *** NZ (zip) to enter your zip or postal code. ex: NZ N5X1G8 (no blanks) *** MailBox can't do it. *** None found. *** Not your message. *** There already is a file with that name. *** Timeout. *** What? *** Done. *** No such port. *** No such directory. *** File not found: $H *** Message not found. *** Port is in use.